Project Forecasting and Uncertainty

Yesterday, I posted about the need to focus on time remaining, using a driving analogy. The premise was that, if we were traveling from Philadelphia to New York and we were at the New Jersey Turnpike entrance (and assuming arriving on time is a critical success factor), the best predictor of success would be to determine how much time remains on our trip.

But what if arriving on time were not the most pressing need? And what if we increased the uncertainty factor? Is "time remaining" still something we can and should monitor?

Let's take IT research projects, for example, which tend to carry great uncertainty. Using an agile approach, the team builds prototypes, and the deliverables get ever closer to "the truth" as the project progresses. If we used a fixed set of iterations, and/or fixed-time iterations, we still benefit from focusing on time remaining, possibly even more so. The only difference is, we're operating in increments.

And even if time is not the ultimate concern, any customer will still want to know "How long will it take before I see something of value?", and usually, "How much will it cost me?" These are the basic fundamentals of good customer service. We still need objectives and scope statements, even on agile projects. It's just that we recognize uncertainty more.

And speaking of uncertainty, proper preliminary research and planning can often help reduce it, and contingencies or buffers can help prepare for the unexpected. Piecemeal deliverables (iterations) can also help, as learnings can be applied to the next phase.

The Five-Minute Project Manager

Sometimes the best project management tips come from other fields, such as this free "Five Minute Guide to Project Management" from a creative arts website.

Simple, to-the-point, and yet quite effective, this brief guide reminds us of the basics that so often get forgotten in the midst of earned value, critical path, and other favorite topics of PM nerds.

As the article discusses creating a project plan and formally managing subsequent revisions as part of a "contract" between you and the sponsor, let's not forget the importance of defending the right plan.

I was having lunch with a group of CIOs the other day (following a presentation I had done), and all agreed that the number one killer of projects was an unrealistic plan, often agreed to under duress by an intimidated project manager.

Several CIOs present shared success stories of making a case to other senior executives by way of a high level project schedule, outlining the steps needed to achieve results. Often, that's all it takes. Some people I've spoken with have had some luck backwards-scheduling as needed from a given target, either to demonstrate the futility of the desired target, or to raise discussion as to which items can be eliminated.

Anyway, I digress. Here's the article about the PM basics ...

creativepro.com - The Art of Business: Project Management for Creative Professionals

Project Management and Driving: Staying Tuned In

It had occured to me the other day that project planning is a lot like driving a car. If you constantly look down at the road in front of you, you won't be prepared if traffic suddenly stops or changes pattern. It's better to look out at the near horizon.

And if you listen to the radio for the traffic reports, you'll be able to avoid problems before you even see them.

It's the same with project management. We need to focus on the current planning horizon as far as we can reasonably see (usually we can only see three-to-six months out with any degree of accuracy). And it's equally important to stay "tuned in" through networking, reading what's happening in your organization and the world, visiting your customers and stakeholders, and practicing MBWA (Management By Wandering Around).

The more we're tuned in to internal and external activities that could impact the success of our projects, the better position we'll be in to address problems proactively and head off a traffic jam or a change in pattern.

Project Execution

Tom Peters and crew on strategy implementation through execution ... here's a chance for the project manager to shine ... Get the leadership support. Break the plan into chunks. Schedule the first chunk and resource the team. Start driving. ... Sounds simple. ...

... "Great execution happens in small manageable chunks by taking large plans and breaking them into manageable parts. Otherwise, the path to execution can seem so overwhelming, people can't conjure up the energy. " ...

Via tompeters!: Execution through Projects

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Project Weekly Tasks: Google Personal Homepage

Neat widgets to webify your project tasks and maintain visibility to your weekly work plan, if you use Google's homepage and personalize it. ...

... "You can now review your tasks alongside your calendar, mail, weather forecasts, and feeds (you can choose from hundreds of gadgets to personalize your page). " ...

Via Remember The Milk - Blog: Track Tasks with Google Homepage

Traditional vs. Agile Project Management: All You Need to Know

Here's the best article series I've seen to date comparing traditional "plan-driven" PMBOK practices to Agile "value-driven" approaches. It's a four-part series by Michele Sliger on StickyMinds.com.

Enjoy...

Column info : Relating PMBOK Practices to Agile Practices - Part 1 of 4

Project Management Training: Foundation For Success

With federal IT investment slated to increase, info technology professionals in government would be well-served by training in a foundation of project management basics. ...

... "officials interviewed for the study said their teams lacked or may lack sufficient training to effectively estimate costs, identify risks and develop baselines from which to plan project costs, schedules and technical requirements. " ...

Via Federal Times: Link

Extreme Project Management: Reality Rules

I just finished reading Doug DeCarlo's book, Extreme Project Management. I met Doug at a recent PMI event we both presented at. Not only is his keynote presentation a crowd pleaser (hint: he plays the drums to illustrate the pace of a typical project and uses Noah's Ark as a sample project from the "ultimate Sponsor"), but his book is chock full of practical, immediately usable ideas.

I was amazed at how much his philosophy mirrors my own, with a focus on simplicity, value, results, and the understanding that change is inevitable. A key point of Extreme Project Management is that reality rules. Plans are nice, but then results must drive further planning instead of assuming reality will yield to the plan.

As an example of simplicity, consider what he calls "The Four Business Questions":

1) Who needs what and why?
2) What will it take to get it?
3) Can we get what it takes?
4) Is it worth it?

As another example, check out his "Three Sentence Project Skinny":

1) Who will do what for whom?
2) This project will be considered completed when: ___
3) Why? This project supports the organizations objective to: ___

The book also offers handy checklists (such as what to ask the sponsor during the first and secend meetings, etc..), the 4 Accelerators, the 10 Shared Values, the 7 Win Conditions, and more.

Although the book is the size of the Encyclopedia Britannica, it's extremely readable and has diagrams that bring together all the concepts in the book. I highly recommend it to anyone looking for a book grounded in reality as opposed to academic theory. Above all, this will help project managers succeed where the rubber meets the road---communicating and dealing with stakeholders.

Amazon.com: eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility: Books: Douglas DeCarlo

Project Gates: Are Kill Points Really Considered?

Since capital is usually constrained in most organizations, are we really making the best use of our project stage-gates as potential kill-points? Are we fully considering the cost-to-completion, the probability of realizing the original benefits documented in the business case, or a declining ROI if costs escalate? We will be doing a service to our organization if we take some time to develop exit criteria and consider alternatives at the project stage-gates. There's always another project in the portfolio. ...

... "The Project Plan should have included a schedule for steering committee meetings and other key points to ensure regular tracking of project progress and release of status reports. Additionally, the plan should have identified milestones and project kill points, that is, go/no go decision points for the action of senior management, the steering committee or other authority. " ...

Queensland University: Controlling phase

Innovation Needs a Process Too

Gerald "Solutionman" Haman was recently interviewed on Innovation Tools about...well..his innovation tools. And he has quite a few. An impressive list of clients have used his KnowBrainer pocket tool to generate ideas that directly led to huge profits.

The tool makes use of his "Accelerated Innovation Process," which outlines four steps. According to Haman's site, "the four steps include: (1) Investigate Needs, (2) Create Ideas, (3) Evaluate Solutions, and(4) Activate Plans." Haman stresses the importance of "continuous innovation" as opposed to being a short-term or one-time activity.

When you think about it, these four steps are very much in line with Dr. Deming's classic "Plan-Do-Check-Act" model for continuous improvement. Not a bad framework for project management either.

Here's the full interview.

Interview with Gerald Haman, SolutionPeople - from InnovationTools.com

Project Management Texas Style ...

The plan is made. The team is resourced. The baseline is set. ... Help the team have fun and focus. ... Project management inspiration from a great coach.

... "The game planning is over and I don't need to motivate this team. My job now is to settle them down so they can relax, have fun and focus when we need to focus. They can laugh and dance in the locker room but to win we need to balance being confident and focused. " ...

Via Every Game Counts: Texas Coach Mack Brown Blogs about the 3 Things that will Determine a Longhorns Win against the Buckeyes ...

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

Talent and Project Management

I received the latest PM Network magazine from PMI the other day, and several things jumped out at me, especially following my last blog post on the winds of project management changing.

First, Neal Whitten had a great article about how a project analyst (what I've often called a "project control specialist") can be a valuable aid to a project manager by taking on the responsibilities of: project tools management, plan development, sub-plan collection, project support, supporting project tracking meetings, filling in for the project manager at times, and other areas that can free a project manager up to actually lead the project.

It got me thinking about the talents needed for the project manager role, the project analyst/specialist role, and any other roles needed on the project. But more than that, it got me thinking about talent management in general, and what it means to the project management industry.

Just look at these headlines, all from this month's issue:

• Attracting--and Keeping--top talent
• Executive Identity: Project managers should learn to think like executives
• A People Person: Succeeding in project management---and getting what you need from thise around you---requires a well-honed set of people skills
• Virtual Reality: Dispersed project teams are sparking shifts in management and leadership styles

Clearly, the talents needed to manage projects go way beyond schedule, budget, and cost control. Notice I said "talents" as opposed to skills or knowledge. As Marcus Buckingham points out in his excellent book, First Break All the Rules, there is a huge difference between skills, knowledge, and talent. The first two can be taught. The last one--talent--is innate, and cannot be taught.

This becomes clear when you apply Buckingham's definition of talent as "ANY recurring patterns of behavior that can be productively applied." Everyone has talent. It's just a matter of discovering it and matching them to the right role. The key point is that a person's nature cannot change that much, so it's important to select someone with the right talents (i.e. innate traits). Once that's done, you need to set clear expectations, motivate the person (through praise and recognition of their strengths), and ultimately develop the person (building on the strengths that already exist instead of fruitlessly trying to fix weaknesses).

So what does this mean to the project management field? Everything. It means we need to begin thinking about these innate talents when we hire and assign project managers, when we staff the project, and when we consider how to motivate the team. The talents needed for each role will be different. And, based on the nature of the project and the stakeholders involved, the talent required to manage each project may be different. There is no "one size fits all" when it comes to talent selection.

It's not that skills and knowledge aren't important, but these two items without the correct talents will not bring about success.

What I like about Buckingham's book is that it's based on facts---years of research with the Gallup organization. Anyone who selects and manages people should read this book. And when you do, think about the diverse talents needed for each person on your team, and for the project manager role for each individual project.

Project Management Lessons From the Other Napoleon (Hill)

I've written plenty about project management lessons from Napoleon Bonaparte. But there's another Napoleon with equally valuable lessons---Napoleon Hill, author of Think and Grow Rich.

For those not familiar with Napoleon Hill (who, ironically, also found inspiration from Napoleon Bonaparte), he wrote Think and Grow Rich in 1937 after spending years of research on the habits of rich and successful men at the request of Andrew Carnegie. For his book, Hill interviewed some of the most famous achievers in history, such as Thomas Edison, John Wanamaker, Charles Schwab, Henry Ford, Woodrow Wilson, FDR, and others.

From the book, here's how Napoleon Hill describes the way to go from desire to riches (by substituting the word "money" with "objectives," we can apply the same lessons to successful project management). My comments are in brackets.

1. Fix in your mind the exact amount of money [exact objectives] you desire. It is not sufficient merely to say, "I want plenty of money." Be definite as to the amount [Same with objectives. Be specific].
2. Determine exactly what you intend to give [committments] in return for the money [objectives] you desire.
3. Establish a definite date when you intend to possess the money [objectives] you desire.
4. Create a definite plan for carrying out your desire, and begin at once, whether you are ready or not, to put the plan into action.
5. Write out a clear, concise statement of the amount of money [scope and objectives] you intend to acquire. Name the time limit for its acquisition. State what you intend to give in return for the money, and describe clearly the plan through which you intend to accumulate it.
6. Read your written statement aloud, twice daily, once just before retiring at night, and once after rising in the morning. As you read, see and feel and believe yourself already in possession of the money [objectives].

Hill once said, "A goal is a dream with a deadline." He knew the importance of setting target dates and looking at a concise statement of your goals and committments daily. This can be likened to a scope statement and milestones list, which should be read regularly and not stuffed in a folder.

He also discovered the power of positive thinking, what one might refer to as "thinking the future into existence" (hence the title THINK and Grow Rich). He found that, just by thinking of your goal regularly, you attract that which you need to achieve it.

In all, the book offers 13 steps to achieving your desire, be it money or anything else. It should be noted that the book is not just about acheiving money and gets into metaphysics, etc. as well. There's a reason why it has sold 15 million copies to date (the best selling self-help book of all time).

I highly recommend the book to anyone who is trying to achieve a goal, which should be everyone, and CERTAINLY should be every project manager.

For Successful Projects, Think Hospitality

OK, I'm still thinking about the Bahamas. One thing I couldn't help but notice while I was there was a huge project that Cable Beach Resorts is undertaking, which will combine the Wyndham, Radisson, and Nassau Beach resorts into a sprawling mega resort of "sister" hotels with an integrated waterscape to compete with Atlantis.

It began as an $85 million project, but is now estimated at $2 billion (not sure of the reason, perhaps scope creep, surprise costs, or other unknown factors, but more likely this began as a joint renovation effort and evolved into a more cohesive whole as they saw the potential). However, what struck me is the way that they're doing it in phases to minimize the impact on guests. For instance, at the Radisson, where I stayed, they'll do one wing at a time, and during the interim will allow guests to use the facilities across all three resorts. In addition, they communicated heavily to travel agents, the media, and current guests.

It just reinforced to me that all projects, regardless of industry, should be treated as hospitality projects, with customer impact and communication a key part of the plan (and more than a little excitement and fun thrown in for good measure). Just some food for thought.

Software Glitch Fells Medieval Monster

Miss us? Even PMThinkers need to take a few days off for the holidays now and then!

We return with news of a software glitch that has caused the delay of Grendel, a $2.8 million opera about a medieval monster (as reported in Computerworld). I think I've worked with some computer systems that were like medieval monsters, but that's another story.

The LA world premiere was supposed to occur May 27, but has now been delayed until June 8, with the opening performances reclassified as "preview performances."

Apparently, the computer system was supposed to operate a huge, elaborate moving stage.

This sounds like the "perfect storm" of project risk---an extremely complicated software endeavor with high uncertainty, a firm "go-live" date most likely booked well in advance, and no contingency plan (since "the built-in stages and moving props are too heavy to be operated manually").

Here's the full article...

Computer glitch delays opera opening

Project Management Lesson from Carpenters

No, not the brother and sister duet, I'm talking about real carpenters. There's an age-old axiom used by carpenters: "Measure twice, cut once." Experienced carpenters know that there's no turning back if you made a mistake measuring once the wood is cut.

This is good advice for project managers as well. Many errors, and many hours of rework, can be avoided if you take the time up front to do the proper research, planning, and risk analysis. It's well worth checking your plan twice, even though circumstances are likely to cause you to deviate from the plan. But even those risks can be mitigated with proper research and meditation up front.

Just like carpentry, the later mistakes are caught, the more costly and devastating they are likely to be. It's better to spend a little extra time up front on your projects to increase the overall speed and success of the project.

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

Project Planning Not All It's Cracked Up to Be

OK, everyone relax, I haven't lost my mind. Of course planning is important. But, as I've been saying for years, circumstances change the minute a plan is put on paper and a good project manager needs to expect uncertainty and know how to deal with it when it arises.

There's a great article in Projects@Work by Roger Bly that supports this approach. Bly talks about how project managers must manage the entire end-to-end process, and recommends taking a collaborative approach, using tools that enable frequent two-way communication and the ability for resources to keep the plan current and reflective of reality (something I completely agree with).

Here's an excerpt...

"A collaborative project execution application can make this process a reality in organizations of all sizes by allowing project teams to successfully tackle multiple concurrent projects. Projects are no longer constrained by static plans produced and updated only by project managers.

A project execution approach also frees project leaders from the mundane work of updating project plans, collecting progress information and reformatting information into status reports. Project plans can be collaboratively built and updated by the project team, often by reusing collateral, deliverables and templates from previous projects."

Far too often, a project manager will create an elaborate plan, and struggle to keep it current, ignoring the real issues that occur during project execution. If the team is trained to contribute frequent updates of remaining time (and any changes to the plan), the project manager can spend more time leading and monitoring as opposed to administrivia.

Of course, another easy way to accomplish this is to update the plan and percent complete collaboratively at a weekly meeting on an overhead projector, but it's ideal if the resources can update their own activities electronically.

For more about the need to focus on execution and communication, read the full article...

http://www.projectsatwork.com/content/Articles/231152.cfm

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO

PMO Charters

Jerry's post about PMO success and failure experiences reinforces the point that it's essential to have a clear plan for what a PMO is intended to achieve. With that goes the requirement for all the usual requirements for a successful project - one to set up the PMO. What is it for, how will it be funded (from 5 to 15% of an enterprise project resources), where it will fit in the organisation. The charter for a PMO needs to be comprehensive.
The templates at the CVR-IT link below include a link to a PowerPoint presentation outlining PMO charter considerations.
Index of Project Templates

Project Goals and How to Achieve Them

Sometimes answers come from the strangest of places. I've been reading Jeffrey Gitomer's excellent Little Red Book of Sales Answers, which went to #1 on Amazon.com this week. There are many eye openers, and more than a few tips that project managers can benefit from as well.

For instance, here's what he has to say about the 3.5 reasons why people don't achieve their goals (by the way, he defines a goal as "a dream --- with a plan and a deadline")...

1. Failure to write your goals down and post them in plain view.

2. Failure to make a plan to achieve the goals.

3. Failure to commit, or live up to the commitments they made.

3.5 Failure to make goals that were achievable in the first place

I can say with certainty that every one of these are critical. Many people don't put goals in writing, nor do they develop a plan to achieve their goals. And even if they do, it's not always a realistic plan that considers all the angles.

With projects, like anything we're trying to achieve in life, we must begin with the end in mind. Or, as someone else once said, "If you don't know where you're going, you're probably not going to get there."

The book is chock full of simple formulas like this, that are useful whether in sales, project management, or in life.

PS: See my post from April 8th, Project Managers; Secret of Success Found, for a neat little story about JP Morgan. I think we have a "keep it simple" theme going here.

Recovering Troubled Projects; Seven Steps to Turn it Around

I just read a good case study about rescuing a troubled project, written by Jim Stewart on Chief Project Officer (which, incidentally, has a nice selection of articles).

Here are seven tips Stewart suggests:

1) Don't continue down a failed path. It's never too late to add controls.

2) Don't be afraid to cut your losses and terminate a project that's not generating value.

3) Be sure you have experienced, trained project managers. Keep the good, trainable ones. Reassign the others.

4) Be prepared to make tough decisions. Bypass groups that'll slow you down. Remove troublesome spots (or people).

5) Have adequate and appropriate resources. Allow project managers to focus on project management, not day-to-day technical details or deployment.

6) Don't hesistate to reconsider everyone's role. Avoid redundancy and joint-leadership situations.

7) Re-plan the project with team input. Avoid an unrealistic plan set by management. While management input is valid, only the team knows what's wrong with the project and how long everything should take. Getting team input insures a realistic schedule and garners team buy-in.

Here's the full case study with the lessons...

Chief Project Officer: Case Study: Recovering a Troubled High Tech Project

Project Risk Control vs Innovation

Winston Churchill once said, "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity."

As project managers, we are taught to focus on reducing or avoiding risk, but all too often we forget that a good risk management plan should include opportunities as well. Sometimes those opportunities will carry additional risks, but if the benefits are worth it, we need to exploit those opportunities. Certainly we can---and should---try to mitigate the risks, but the point is that in focusing on the dangers, let's not overlook the opportunities.

When framing a project, it's important to see for ourselves what the customer's situation is, and get engaged an an "opportunity assessment." As Tom Kelley of IDEO pointed out in The Ten Faces of Innovation, Henry Ford said that if he'd merely asked customers what they wanted, they would have said a faster horse.

Of course, not every opportunity will make it into the scope of the initial project, but at least there can be a plan to exploit it.

So, using Winston Churchill's axiom, should project managers be optimists or pessimists? I'd venture to say we need to be a little of both, and the right balance is the art of project management. For more on how innovation and project management can and should coexist, stay tuned for my upcoming post on the relevance of Tom Kelley's book to project managers.

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.