Do you have a Hovercraft?

I enjoy the recent Orbitz (the travel company, not the gum) commercial, where an average guy watering his yard is interrupted by a landing of the Orbitz Hovercraft.

The pilot emerges to hand the guy a refund check, because after he booked his flight, the prices dropped and he was entitled to a refund for the difference.

"Why didn't you just mail it?" the confused homeowner asks.

"Because we have a Hovercraft!" is the reply.

And so it got me thinking. How many work processes exist because they can?

The "Magic" of Getting Things Done

I am continually amazed at how often people fail to demonstrate the ability to "get stuff done".

Some call it a failure of leadership. Some say it's due to a lack of organization. Or maybe it's simply poor implementation skills. Or a lack of a coherent strategic vision.

Truth is, it could be any (or all) of these things.

I am not an expert, but I have learned a few things over the years.

The first, is. If you have ten #1 priorities, you don't have any priorities at all. You simply have a list. And the problem with an unprioritized big list, is that it allows those responsible for the list to "touch" each task, without ever moving any single one forward significantly. The "overhead" it takes to juggle ten initiatives soaks up valuable time you could be spending on completing a task.

So, prioritize. If necessary, trim the list to a few key items. The rest can wait. Truth is, you're not making much progress on them anyway, so where's the harm?

The second rule is to assign ownership to each task. If a "team" is responsible for the completion of a task, no ONE person owns the outcome. And so each team member gains comfort in the thought that a lack of progress is probably someone else's fault.

Thirdly, ask yourself, "Have I engaged the right resources?" For example, if you're undertaking a revamp of your Job Costing processes, do you include shop floor supervisors who collect and assign labor costs? Is purchasing involved? Receiving? Accounting? Do you need someone from payroll to verify that labor hours assigned to jobs balance to payroll hours? Identifying all the process "touch points" and securing the involvement of expertise from all areas, is a basic requirement to move forward in any substantive way.

Fourth, "paint the picture". Help your team understand why this initiative is a priority. Paint the picture of what the future process might look like - what the business benefits of improvement are. Establish buy-in from the team. Remember that these people already have full time jobs. Just because they're on your team doesn't mean you have their support or buy-in. At the end of the day, each participant should be able to understand "what's in it for me?"

Fifth, parse the project. Large change initiatives are scary and daunting. If you can break up your project into manageable and easily understood milestones, you improve team understanding of each task and can easily measure progress. I always think of the old joke: How do you eat an elephant? (Answer: One bite at a time.)

Sixth. Spend your time executing the tasks, not managing the project. Use tools that allow for simple collaboration and project updating (SharePoint, Basecamp, Google Docs) - whatever works for you. This will allow you less time in meeting updates and more time to address issues and make decisions.

Careful observers of these rules will have, by now, understood the "magic" of getting things done. Design your project by providing answers to the questions: Who, What, When, Where, Why and How?

The Power of Tempo

I've always struggled to restrain my internal "sense of urgency". In business, my personal bias has always been toward action. And lots of it.

Some may argue that my approach resembled; "Ready, Fire, Aim!".

I think that's a typical response to someone who really wants to see things happen quickly. The reaction is "Not so fast!" or "We're being too reckless!" The danger in eliciting these responses is that it creates the opposite effect.

Instead of increasing the pace of work, people "dig their heels in" and resist, rather than getting on board and fast tracking a solution.

The business challenge works just like a Chinese finger puzzle. When you insert your fingers in each end of the tiny tube and then try to pull your fingers free, the puzzle grips your fingers more tightly. What seems like an obvious solution to the puzzle is the wrong one.

I've learned a more effective approach is to gently increase the tempo of work. Think of it like a metronome. By gradually increasing the tempo over time, your team will work at an improved pace - something they might have resisted, had you attempted the increase in one big jump.

Try breaking the habit of weekly progress meetings. It's very easy to fall into the trap of meeting on a regularly scheduled basis. Sure, meeting every Friday at 9am is easy to remember, but it imposes a certain pace on the project.

So break the habit.

Try meeting on Mondays and Thursdays. Set the unconscious expectation that the same work will happen before each meeting. What was once a ten week project, becomes a five week project. Simply meeting more frequently to report on progress, sets the expectation that progress should be made.

You begin to break that old college habit of starting the term paper the night before it's due. With weekly business meetings, the work usually gets done the night (or hour!) before the meeting.

Increasing the meeting frequency also allows you more frequent opportunities to reset expectations.

"Guys, it doesn't have to be perfect. It just has to BE!"

Let's get our prototype up and running, set the right expectations with our internal customers (let them know it's a prototype), allow people to use it. Then improve it.

Our goal is to make version 2 bug free. Let's not try to architect perfection. Let's built it based on user/customer experience.

The longer term benefit of increasing the pace and NOT trying for perfection, is that you begin to develop a learning organization. Expect some mistakes and begin to see them as improvement opportunities. "Blame" is expunged from your team vocabulary. And as the rapid prototype mindset takes hold, you begin to see other incremental improvement opportunities in every process you use.

By looking at each opportunity as a challenge to improve through "tweaks" and multiple iterations, you slowly empower your team to identify opportunities on their own. Not all changes have to come as a result of a big project. Teams can make a big impact my making incremental progress on lots of smaller projects too.

Finally, remember that Teams Win and Coaches fail. If the result of one of your accelerated projects is less than expected. Take the heat for your team. If you're asking them to take a risk by developing 90% solutions, you had better provide "cover" for them. And when the team has success, give them ALL the credit.

I think you'll be pleased with the results.

Here are the Cliff notes:

1. Gently increase the tempo.

2. Aim for a 90% solution.

3. Pilot and improve.

4. Migrate to a learning organization.

5. Take the heat, when necessary.

The Paper Herd

It was only recently that I've come to notice the herding instincts of paper.

Almost as soon as it comes through the network or desktop printer, it seems to search out others of it's kind.

Printing on paper, is just usually the first step in a long process of non value adding activities that seem to attach themselves to that innocent, first piece of printed paper.

Once it's printed, then

• it is collected from the printer
• it's fastened, sorted, stapled, folded
• it is physically transported around the office
• it waits in in-boxes for work to be done to it,
• in a serial process (only one person can work on the piece of paper at a time), then
• it is wrapped in a file folder
• which is stored in a file cabinet
• which is contained within a file room, where
• it's retention must be managed, after which,
• it is stored in an offsite facility, where
• it is utimately shredded, discarded or recycled.

So much non value adding activity surrounds EACH piece of printed paper, that one wonders why we haven't tried harder to achieve the "paperless office".

Are our customers really willing to pay for all of this? I don't think so.

I think the reason is, I.T. guys like myself, push paperless technology, rather than making a case that printing paper launches a series of non-value adding activities that are really expensive in aggregate.

What we failed to do, was make the cost benefits case.

Businesses understand costs pretty well. And if they are to change behaviors (like printing), there had better be a good reason for it.

Want to go paperless? Try demonstrating the herding nature of paper to your company.

The Journey to Lean and Agile

When you search Google for images using the keyword "Agility", Google returns tons of pictures like the one at the left.

Lots of dogs running through obstacle courses. The other general image is of athletes running a tire drill.

What the search doesn't return are pictures of businesses or processes.

Perhaps it's difficult to convey the concept of an agile process or an agile business in an image.

Or perhaps, examples are difficult to find.

I'm currently doing some work for a family owned manufacturing company who want to investigate lean manufacturing. Like every business that has contemplated change, the potential rewards (less waste, faster processes, less process cost) will be challenged by past success (always been profitable) and a stable long term workforce, who have always done things the same way.

It's a classic struggle - one that EVERY company goes through.

Judging by the fully booked schedules of the Lean Process consulting companies, our company is not alone in the desire to be lean.

(Aside: If you're a consulting company who claims to be an expert in Lean Processes and can't find a way to return a customer call, perhaps your processes need improving?)

The journey will be exciting, scary and hopefully beneficial. Over the course of the next few months I'll document our progress, challenges and successes and perhaps we can share learning experiences along the way.

Disagreeing with a Hero

I recently read a column in Expert Voices at http://www.cioinsight.com/ called CIO as Chief Process Officer, not Strategic Leader.

It's a summary of a conversation with Dr. Michael Hammer - a hero of mine, who invented the word re-engineering and along with James Campy, wrote a terrific book called Reengineering the Corporation. I've seen Dr. Hammer on several occasions, listening to his advice on How to Succeed with SAP. Believe me, he knows what he's talking about.

The latest article is a continuation of his thinking about Process reengineering, and he espouses a new theory that CIO's should become CPOs - Chief Process Officers.

While I agree with much of what he says, I have a hard time completely swallowing the concept. Yes, CIO's are generally very familiar with company processes. Their departments support the technology that support the processes and they have an extremely good "under the hood" view of how things work together - or not. And it's for this reason, that Dr. Hammer believes they should become process champions within their organization.

Good reasons all, but it rings a little hollow with me. Here's why.

Once you anoint a Process Guru, almost instantly, you excuse others from the responsibility. "I don't have to worry about process - that's Dave's job" - is a sure path to failure. We tried the same model with the CIO role...before the advent of I.T. Steering teams. Steering teams brought in other executives into the technology decision making process.

And overall, companies use of technologies, investment, project selection/prioritization and execution benefited as a result.

Dr. Hammer points out that successful processes require strong leadership, the right metrics and commitment. But he's a little vague on how to get there.

It's a little like the old joke: "How do you make a million dollars in Real Estate?"
Answer: First, start with two million dollars.

I think that answer may lie in Process Steering Teams. Senior executives need to agree which processes need improvement, determine the success metrics, provide the necessary process training/education and dedicate the bset resources to help redesign the processes (usually achieved through value stream mapping exercises). They determine where the pilot should begin and who should be involved in the process. Compensation plans need to be aligned with process improvement goals.

To me it's exactly the same challenge as Change Management. Successful efforts are driven by all top leadership. It's a priority for the company - not just a project of the week. The ultimate goal of the Process Steering Team shouldn't be to refine derelict processes. It should be to turn mid and lower level managers (in fact, all employees) into process champions.

The ultimate goal should be to have everyone at your company focused on process inefficiencies - not just a CPO.

Toyota is generally regarded as the platinum standard for manufacturing efficiency. Their processes are no secret. The huge challenge in imitating Toyota's success is that lean processes are part of Toyota's culture - ingrained through decades of process focus. The other huge benefit that Toyota garners is standardized processes. Everyone uses the same processes. To accomplish this, everyone must understand the process, why it works and what the success metrics are.

Process innovation can't be sustained by one person.

It's everyone's job.

And until we recognize that making and executing lean processes is everyone's goal, new CPO's may suffer the same fate as many early CIOs - very short tenure.

Business Led or You're Dead

Somewhere in the midwest, storm clouds are brewing over yet another ERP implementation project. In about six weeks, when the project is expected to go live, the ABC company (name changed to protect the guilty) will learn that many of the process decisions they've made are wrong. The new automated processes will actually be slower and more cumbersome than current processes. Their staff will be completely unprepared. Things will grind to a halt.

It will be an unmitigated disaster.

How do I know this? Unlike the company, I spent an hour or so listening to the Project Manager.
His client company is a leader in its industry. Their past success is making them "hard of hearing". "Just make the system do what we've always done." they say.

Which should beg the question; "Why not stick with the legacy system?"

What they don't understand is that to achieve meaninful improvements, you actually need to change something.

ABC's expectation is that by simply installing a world class ERP system, their processes and operational performance will improve as a result. Nothing could be further from the truth.

That same reasoning would have you purchase a pair of Air Jordan basketball shoes with the expectation that you'll be playing guard for the Chicago Bulls.

Not gonna happen.

Operational excellence is achieved with three ingredents; great people, great processes and the right tools. A new ERP system is just a tool. Just one componant.

Installing a new system is an opportunity to re-examine the way your company does things. A chance to simplify, to optimize, to take a fresh look at the way things are done. It's a chance to re-educate yourself in how your company processes work. If you don't do this on a regular basis, you'll be surprised at the difference in the way you think processes work and they way they're actually done.

Reviewing processes takes a big investment in time and resources - business resources. Unless the project is business led, you simply can't pry loose the key people who can make a big positive difference in the outcome. Everyone is too busy "doing their regular jobs" to devote any time on the project.

It's the Number 1 reason ERP projects fail.

(Shameless plug) If your company is contemplating a major I.T. project in the near future, may I suggest you check out my e-Book entitled; "Lessons Learned from the ERP Frontline".

It's available by either clicking on the Lulu link on this website or by going to http://www.lulu.com/ and searching on my name or the title.

And best of all, it's free.

Great Grandma's Roast

Stories are wonderful things - especially in business. They're usually told to make a point or to educate the listener or perhaps to evoke an emotion. The good ones are entertaining, easily remembered and easily retold. They're a very effective teaching tool.

And we don't tell enough of them.

They're important to the lifeblood of any organization. Some stories capture a sense of company history. Remember the innovation spirit evoked by early HP commercials with Carly Fiorina standing in front of the shed where Bill Hewlett and Dave Packard invented together at the beginning of their partnership? Nowadays you have to search the HP site to find these stories. Like too many stories, they're buried deep in the bowels of the organization.

And untold stories are assets, wasted.

Sometimes the stories are based in historical fact. Sometimes they may even be made up. It doesn't matter. As long as the stories are entertaining, teachable moments, easily remembered and easily retold, they serve their purpose.

One of my favorites is told by my I.T. teams when implementing new processes. Too often, when you ask employees why they perform a function they way they do, the answer is either;

1. We've always done it that way.
2. That's the way I was shown how to do it.

The real answer of course, is "I don't know."

And then we tell this story.

One evening, while helping with preparations for a dinner with his in-laws, a husband noticed his wife slicing the ends off the roast, before placing it in the pan to be cooked.

"Honey, why do you do that?" he asked.

"That's the way my mother taught me to do it." came the reply.

Later that evening at the dinner table, still curious, the husband asked his mother-in-law about the practice.

"That's the way MY mother taught me to do it." she responded.

A couple of weeks later, while visiting Great Grandma, the husband couldn't resist asking again.

"Great Grandma, I have to know. Why do you always cut the ends off the roast before putting it in the pan to be cooked?"

"That's easy dear. My roasting pan is too small to fit a big roast." she replied.

I don't remember who first told me this story, but I've never forgotten it.

Swiss Army Applications

Why is it that precious few "productivity tools" actually make me more productive?

I think it's because productivity tools are designed to make their designer more productive, not me.

And I think that explains the rising adoption of applications like widgets and gadgets - snippets of single purpose code which can be assembled on a desktop to address small specific needs - as an alternative to a "full featured" office productivity suite.

You pick and choose just what you need and ignore the rest.

Maybe that's why I never owned a Swiss Army knife. I didn't like the idea of always carrying all the tools around, whether you'd ever need them or not. I could I never get one to open up and I didn't know what half the tools were for!

Simple is Hard

For the past few days, I've been working on developing a web application with a partner of mine. Our goal is to offer an application that is intuitive to use and contains just enough features to make the application extremely useful. A small software company called 37Signals has long professed this philosophy.

Being an old time I.T. guy, my DNA drives me to design feature rich applications, where every conceivable need is addressed. Too often, the result is an application that is so complicated, that no one uses it. The kind where you need to provide an hour's training for a 5 minute process.

For our latest project, we began by brainstorming all the possible features we'd "need".

And then we spent three days eliminating most of them.

Just when we thought the application couldn't get any simpler, I invited a friend over, who happens to be a subject matter expert (and a potential customer). I can always count on him to give me the unvarnished truth.

Three hours (and four beers) later, our application had lost another 30% of it's features, and 50% of the copywriting had to be changed.

I've learned a few things from this experience.

It's very difficult to get outside one's own head - to really see the project from the customer's perspective. To eliminate your biases. To expose your assumptions. To fight against the compulsion to complicate.

Simple is hard.

Good to Great I.T.

With apologies to Jim Collins for the title of this blog entry....

It seems to me that most companies judge the performance of their I.T. departments in two ways.

1. On infrastructure: Do things work? (And if they break are they repaired quickly?)
2. On Project Management: Do projects get completed on time and on budget?

If the answers to these two questions is Yes, congratulations! You are good.

These are pretty basic measures. Obviously we all want our PCs and laptops to run flawlessly. The applications shouldn't crash. Our website should not be down. We need to run in a secure environment. I call this executing basic blocking and tackling - the fundamentals of I.T. infrastructure management.

And secondly, we judge I.T. on project management and execution. if we're going to give the I.T. department millions of dollars to implement that new system, they had better not run over budget, miss deadlines or provide a system that doesn't work.

Of course for more sophisticated companies, I.T. excellence is measured on multiple conditions - I.T. strategic alignment, Physical and intellectual data security, Infrastructure Change control processes, Sarbanes-Oxley compliance, Governance, cost control, ISO certification, among many more....

But in the end, the average internal customer rates I.T. on two axis. Infrastructure and Project execution. If you do those things well, you have a good I.T. department.

I'm not going to spend much time telling you how difficult it is to execute these two metrics flawlessly. It takes dedicated, hard working, excellent employees, using good processes to make this happen. But for those of you who have managed to execute on these two major tasks, where do you go from here?

How do you get from Good to Great?

The short answer is: Business Process Execution. Now that you've provided the infrastructure and given the business the application tools, partner with the business to make sure the tools are used well - that the processes are being executed flawlessly.

How do you do that? Here are some suggestions.

1. Keep your eye on the prize. When big systems are justified, many times they're paid for with expectations of cost reductions or revenue enhancement or cashflow improvement or improved inventory turns. Make the business goals, I.T. goals. In the systems department, your job isn't done until the business benefit is achieved. (Makes any discussion about "I.T. alignment" moot.)

2. This forces you to look beyond launch date of the system. It says you must partner with process owners and managers to improve transaction execution, to achieve those business goals. This takes frequent, open and honest dialog. It requires partnering with your business counterparts.

3. Understand that the system itself doesn't guarantee anything. It amazes me that many smart executives expect that once a system is installed, the benefits should "just come". That same reasoning would have us install the latest version of MS Word on your computer, then sit back and wait for you to write the next Harry Potter novel!

4. Help your business counterparts understand the process, monitor the process and execute the process. In some companies (especially big ones), you might be amazed to learn that no one actually understands the end to end business processes. Departments become so specialized, that they only understand their jobs from their in box to their out box. They have no appreciation for what happens before the task reaches them, nor the affect that their work (if poorly executed) has downstream. This takes time, patience and coaching - words seldom used in technical I.T. job descriptions. Integrated systems are not very forgiving if the integrated tasks aren't performed properly. Transactions just stop.

5. Compensate your I.T. staff for obtaining positive business results. Make positive business outcomes into performance goals for your staff.

For example, the Purchasing Business Analyst might have a goal of reducing PO exception processing to less than 5% of all POs issued. Or perhaps should share a goal with Purchasing management to identify x% purchasing cost savings.

Your Payables analyst might have a goal that automated three way match processing should handle 90% of all payables transactions, or that prompt invoice processing should result in 100% allowable discounts.

Your Financial business analyst, might have a goal of shortening the monthly or quarterly close to x days. Or to automate all monthly journal entries.

6. Good I.T. functions still speak in terms of "us and them". Great I.T. departments speak in terms of "we". Once you've blurred the boundaries between business functions and I.T. support functions, you know you're headed on the path to Great.

Process Barnacles

Just in case you aren't a seafarer, let me tell you a little about barnacles. Barnacles are small sea creatures which attach (cement) themselves to (among many things) ships' hulls. Attached is a picture of what they look like.

Barnacles are a big nuisance for the shipping industry. Here's why.

"It has been known for some time that barnacles, mussels and algae cause up to a 15 percent increase in the drag resistance of ships, which drives up fuel bills and hampers a ship's performance." You can read the entire article here.

Barnacles attach to hulls below the waterline. After all, they're sea creatures and they live below the surface of the water. Hundreds or thousands of barnacles can attach themselves to the hull of your ship, and you'd never know it, standing on deck.

But you'd feel the effect. You'd use more energy just to keep the ship moving forward. Your ship would be more difficult to steer.

So why are we talking about barnacles?

Well, think of your company as "a ship". With sleek, well engineered processes, your "ship" has a clean hull, (no drag) and uses a minimum amount of energy to get you where you want to go. You're maneuverable and can react to changing market conditions.

But over time, processes tend to evolve, change, out of view of senior management - below the waterline. An extra report here. Another form there. More approvals required for this task, additional reporting on that task, more meetings, less decision making, after the fact quality checks, inspection departments are formed, safety departments spring up...

One by one, these process "barnacles" begin to attach themselves to your hull. And before you know it, "your ship" is in trouble. Lethargic, not maneuverable, expending energy without desired results.

So what's the lesson in all this? Think about every proposed change in "end to end" process terms. When faced with a process or task breakdown, companies like Toyota, ask WHY? five times. They feel that this is the only way to really understand the underlying cause of an issue. They seek to solve the source of the problem, rather than to quickly address a symptom.

Dive into resolving the real problem - personal performance, lack of training, poor execution. If your processes need work, explore the root cause and fix the process. You likely don't need that extra form or the extra report or the extra approval.

And your ship will stay barnacle free.

Lean I.T. is Waaaay Overdue

Try as I might, I can't find a really good example of an organization devoted to Lean I.T. - that is; a company who continuously drives out waste from its I.T. processes.

Jeffrey K. Liker, author of The Toyota Way, has spent decades studying Toyota, who happen to be the most efficient manufacturing company on the planet. It's Toyota's passion to identify and remove "mudo" (waste) from all of their processes.

They describe waste as:

1. overproduction
2. waiting
3. unnecessary transport
4. overprocessing
5. excess inventory
6. unnecessary movement
7. defects
8. unused employee creativity

None of these activities add value, (as defined as something a customer would be willing to pay for) so when stripped away, the idea is to leave behind a process that ONLY adds value.

While America has embraced the notion of Lean Manufacturing (to varying degrees of success), I haven't found a great example of how lean principles are being used within I.T.

Consider the massive amounts of administration and management that go into every large I.T. project; the documentation, the approvals and sign offs, the numerous team meetings to "get everyone on the same page", the status reporting, document filing, retrieval etc.

Even the physical organization of the project should be scrutinized - are all the team players together in the same place or are they dispersed across several sites or across the organization?

Have you ever done post project forensics on your PM processes to determine which activities add REAL value? If you had to defend all the documentation you currently complete to your peers in other departments, could you do it? - even down to every box on every form?

I ask the question, because after Sarbanes-Oxley, it seems to me that the knee-jerk reaction is to document the heck out of every project, (regardless of risk) and whether or not the documentation adds any value.

And I think our I.T. processes have suffered as a result.

I have actually come across examples where for some small I.T. projects, managing the project is 80% of the work and the actual activities DOING the project (designing, coding, testing, implementing) amount to only 20%.

Houston we have a problem.

If you haven't looked at your I.T. processes in awhile, I'd recommend bringing in a "Lean Expert" to help you Value Stream Map your processes. VSM is a process whereby you actually, map, step by step, in intricate detail, how you believe a process works. The VSM process identifies "waste" wherever it appears within the process. At the end of the exercise, your team will be able to quantify how efficient your process is. Don't be surprized if you find that actual Value Added work is only a fraction (usually less than 5%) of the total elapsed process time.

Then, you observe the ACTUAL process to see how it works in "real life" and document it again.

Finally, your team identifies ways to cut out the waste. The results can be stunning.

I once worked for a company where VSM was done on an estimating process. The estimating process took about a week from the time we received a customer quote request to the time they had a formal quote back in their hands. After a VSM exercise, our improvement team found that over 70% of the quotes they received could be completed within 20 minutes. The actual value added work, in a process that took a week, was only 20 minutes! The rest was "waste".

Is lean I.T. long overdue at your company?

Do you suffer from PM Bloat?

A colleague of mine is currently doing some consulting for a major local company. He's noticing an interesting phenomenon. His client is suffering from "PM bloat".

PM bloat is a condition whereby the management portion of an I.T. project becomes a disproportionately large piece of the overall project. His example? They're currently evaluating a project that will take about 50 hours of "actual work" (configuration, testing, training) to complete. The overall project time frame is 300+ hours! That's right - the paperwork, forms checking, collation and rechecking, approvals, pre-SOX audit, reviewing of each deliverable, will take 5 times longer than the actual work.

The project management is getting in the way. And no one within I.T. is noticing!

Here's some reasons why this may be happening.

1. No one has looked at the overall process with an eye towards making it "lean" (eliminating waste in the form of time, checking, rechecking, workflow, approvals etc). I suspect that the PM process grew organically over time or previous processes were modified for better SOX compliance and no one has looked at it since.

2. The process is not automated. If your I.T. processes involve paper, they will be MANY times slower (read: expensive) than if document storage and workflow are electronic. They're also more time consuming to move, file, store, check, retrieve and audit.

3. Each person within the process must be held accountable for the completion of each step. Processes that include excessive double checking aren't designed very well.

4. Make sure that each steps adds value. Question every box on every form. Why is this necessary? Where does this add value? What would happen if we got rid of this piece of information? Why does this need to be verified?

5. Set up appropriate documentation specific to the project. If your IT project is implementing a service with an ASP, it's a different project than developing a customized application from scratch. But I bet your project documentation requirements are the same.

6. Don't accept the excuse "We have to do that because of Sarbanes-Oxley". Certainly you need adequate SDLC processes, but in most cases, if your SOX Control Document is well written (i.e. not so detailed as to cause you compliance fits), your processes can be simplified and still be effective.

So take the PM bloat test. If you're suffering from PM bloat, make your very next I.T. project a review of your project management and documentation processes! Spend more time DOING and less time MANAGING!