Perform to Schedule

Performance to schedule is critical to manufacturing processes. This same discipline needs to extend to project schedules. However, not all projects and tasks are as repeatable as manufacturing steps. And, people aren't machines. ...

... "At the manufacturing level, processes are expected to be adhered to with clockwork precision to meet defined deadlines. With over 6 lakh cars a year from three assembly lines in Gurgaon and 1 lakh from a plant in Manesar, the shop floors need to produce exactly to a plan. " ...

Via InfoWorld Nederland: IT on wheels

Project Forecasting: More Lessons from Driving

A while ago, I entered a post about the importance of staying tuned in, drawing an analogy to driving. Well, another driving analogy had occured to me, this time about the need to focus on remaining time.

Let's put it this way. If you're driving from Philadelphia to New York City and you're at the entrance to the New Jersey Turnpike, what percent complete are you on your trip?

Some of you may guess certain percentages based on distance, but that's as foolish as basing project percent complete on the percent of budget or time that's been spent, without regard for work accomplished.

The quick answer is: Who cares what percent complete we are? What we really should be concerned with is how much time is left, assuming we care about what time we arrive to begin with.

But let's say that we DO care (i.e. schedule is a priority for us, as opposed to some other success factor). How can we measure whether we'll be there on time?

Simply using a percent complete tells us nothing. It's too subjective. What we need to know how much time is remaining. And that will depend on how fast you're going, how many miles are left, what barriers may arise (i.e. road closings, flat tires, etc.), how many stops you make, and a number of other variables. It's no different for projects.

For project schedule control, capturing percent complete is too theoretical, so that's not of much use to us. And capturing time spent tells us very little, except perhaps how long it took us to do prior work, which may not be an accurate indicator of future work. Besides, we can probably determine future work estimates more accurately through expert opinion and/or statistical sampling (combined with good planning).

Of course, there's no harm in entering time spent as long as people are disciplined to always include time remaining. Then a percent-complete can be calculated based on that. But the percent-complete itself is not a leading indicator, so is still of questionable value.

If we focus instead on time remaining at the task level, and combine that with barrier removal, risk planning, and regular reforecasts, we'd have much better control over whether we "arrive on time."

We can improve our ability to estimate in the future by capturing lessons learned, doing spot checks, and using the information to create project schedule templates and checklists, so future projects can avoid running over the same potholes.

Some may say, "Oh, we still need the percent-complete for Earned Value calculations."

Do we really? By putting a dollar amount to the time remaining, we can solve the same problem in a simpler fashion, answering the question: How much is it going to cost us to complete this project and what's our estimated time to arrival?

Just some food for thought. See my followup post on Project Forecasting and Uncertainty as well.

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

Results Project Failure Poll

Communications, resource planning, and scheduling were identified as top root causes of project failures in CompTIA poll. ...

... "Nearly 28 percent of the more than 1,000 respondents to the web poll singled out poor communications as the number one cause of project failure. Insufficient resource planning was the second most mentioned cause of project failure, cited by just less than 18 percent of poll respondents. The third most frequent cause of project failure, according to the CompTIA web poll, was an unrealistic schedule, chosen by 13.2 percent of poll participants. " ...

Via CompTIA: Project Failure - Root Cause Poll ...

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

Impossible Project Becomes Possible

Remediation project of Rocky Flats contaminated nuclear weapons facility demonstrates that the impossible can be accomplished. ...

... "Now on its way to becoming a wildlife refuge, the project is running 60 years ahead of schedule and $30 billion under budget. " ...

Via Line56: KM Blog: Link

IT Project Dashboard

Anecdote on IT project performance with mention of top 5 root causes. Chevron referenced for its management practices that focus attention on the highest value projects in its portfolio. ...

... "According to Accenture, the average IT project exceeds its projected cost and schedule by 56 percent and 84 percent, respectively. " ...

Via ITBusiness Edge: Link

Earned Value Lies and Truths

There was a great quote from Benjamin Disraeli in David Hillson's letter to the editor in the latest PM Network Magazine.

Disraeli allegedly* said, "There are three kinds of lies: lies, damn lies, and statistics."

* As an aside, there's apparently some debate over the actual origin of this phrase.

In any case, Hillson's interesting letter was cautioning those who frequently misapply statistics, and offered some clarification the terminology----specifically, the mean (average), mode (most frequently occuring item), and median (the middle item if all were lined up in order).

I find that many misuse Earned Value statistics the same way. The intent of EVM is to be an early indicator of a potential cost or schedule overrun (and I personally feel that it's better at predicting cost than schedule). However, much like the Ghost of Christmas Future, it's not set in stone. There are many things a project manager can do to get things back in order. More importantly, sometimes there are reasons for the apparent variance that indicate that the variance is explainable and not a concern at all.

The key with EVM (much like any metric) is to not take the statistics at face value, and to use them as a trigger to do further subjective examination. It's a tool, and organizations often overuse such tools (much like they do with Six Sigma). If all you have is a hammer, everything looks like a nail.

Yogi Berra on Project Management

There's a cute article in Computerworld called Yogi Berra, PMP. The article uses the baseball great's famous quips to make some compelling points about managing projects.

Of course, it didn't include one of my favorites as it applies to project management. When someone said to Yogi, "Hey Yogi, I think we're lost," he replied, "Yeah, but we're making great time!"

Unfortunately, this happens all the time in project management. Many methodologies focus on schedule, budget, and execution----and fall short when it comes to defining the problem and goals (and aligning them with the organization's needs). As a result, we end up getting to the wrong place fast.

Here are some other fun Yogi quotations, and here's the Computerworld article...

Yogi Berra, PMP

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

Project Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

Project Management Graphics: Lessons from Edward Tufte

I recently checked an old discussion thread on project management graphics that I had participated in on Edward Tufte's forum. Suprisingly (or perhaps not), the thread is still going strong after four years! It must be the world's longest running discussion thread.

The premise of the thread was to find other ways of portraying project status and schedule beyond the Gantt chart. Edward Tufte, for those not familiar, is the world's leading guru on information presentation.

He was brought in by NASA after both the Challenger and Columbia disasters to analyze why the scientists weren't able to present the facts in an effective enough way to avert the disasters.

Tufte is listed as one of Amazon.com's top 100 nonfiction authors of all time.

For those interested in breaking new ground in project visuals, it's worth checking out. Feel free to participate.

Ask E.T.: Project Management Graphics (or Gantt Charts)

Einstein Project Management Tip #4: Think Value

And so we continue our series on project management tips from Albert Einstein. Here's another...

"Strive not to be a success, but rather to be of value."

This sums up perfectly the problem with most projects today. They focus on "success" without fully defining what success means. Project managers and PMOs track schedule and budget metrics. Then, at the end of the project, some capture customer satisfaction, almost as an afterthought.

What really needs to happen is to insure value to the customer, and this usually goes way beyond being on time and on budget. We spoke about the need for clear goals. Surely that's part of it. We also need to deliver in small, frequent iterations to provide the quickest value and get more immediate customer feedback.

Customer satisfaction should be measured and tagged as an index throughout the life of a project, just as Earned Value uses indices to track cost and schedule performance. This allows course correction to be made in areas such as goal clarification, communication, and other areas needed to provide good value.

And when the product has been delivered, be sure that the customer can maximize the benefits of the product through proper training, tips & techniques, next steps, or any other items that will help them get the value expected.

These are the very items I've attempted to address with my Service-Oriented Project Management (SOPM) framework, with its four phases of Understand, Prepare, Iterate, and Transform (UP-IT).

More Einstein tips coming soon...

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 Winds Are Changing

There's an excellent article by Betsy Morris in the current issue of Fortune Magazine about how the Jack Welch way of winning is---dare we say---a thing of the past.

How is this relevant to the project management field? Well, for one, it means recognizing the winds of change in the industry, and how projects are selected, promoted, and managed. Above all, this impacts program and portfolio management. Particularly, note four trends in management thinking:

Innovation:

Let's take Welch's old rule of being number 1 or 2 in your market (or else fixing, selling, or closing the business). The new rule is to find a niche and create something new. The article uses CocaCola as an example of a company that was basking in their glory as number 1, but eventually realized (although it took a while) that energy drinks and bottled water were about to pass them. As the article points out, energy drinks "are now expected to outearn every other category of soft drink within three years." Parhaps marketing guru Harry Beckwith said it best in Selling the Invisible when he said that it's fine to do something 10% better until someone else comes along and does it 110% different.

Customer-Centric Management:

Welch started a whole movement of focus on the shareholder, which led many organizations to ignore the future amid pressure to appease shareholders and "make the numbers." Now, organizations realize that the customer is king. The article references several companies that have made this realization, and the trend is heading in that direction. After all, statistics show that even a minor improvement in customer retention leads to a major increase in profitability. The days of short-term thinking may be finally coming to an end.

Reinvention vs. Incremental Change:

Since it seemed Jack Welch could do no wrong, everyone imitated whatever Jack did---and Six Sigma was no exception. The problem is that, according to the article, of the 58 large companies that announced Six Sigma programs, 91% have trailed the S&P 500 since. As the article points out, that's mostly because Six Sigma is intended to "fix an existing process," whereas innovative companies that developed new and unique products (or reinvented their business) took the lead.

Stop Ranking Your Players; Inspire Passion:

Once of Welch's most controversial systems was to constantly rank his employees and regularly weed out the "C" players. But companies have had difficulty getting productivity and innovation out of "increasingly disenfranchised employees." In the article, Christopher Bartlett of Harvard Business School put it best:

"People don't come to work to be No. 1 or No. 2 or to get a 20% net return on assets. They want a sense of purpose. They come to work to get meaning from their lives."

Side editorial: For the "enlightened" approach of finding the hidden strength in everyone (something Peter Drucker always suggested), read Marcus Buckingham's Now Discover Your Strengths (or any of his books for that matter). Or read Dennis Littky's The Big Picture: Education is Everyone's Business. I assure you, you'll never be the same.

Meanwhile, I highly recommend the article (the link is below) for those looking for the latest trends in management thinking, and who want to remain one step ahead.

From a project management perspective, the handwriting is clearly on the wall. The traditional "execute to a set of deliverables" approach won't cut it. Today's project manager needs to be thinking about things like innovation, customer focus, business transformation, business acumen, change leadership, and team passion. Those focused on merely schedule, budget, and scope will soon be dinosaurs.

Fortune: The new rules - Jul. 11, 2006

The Distributed PMO: Lessons From Strange Places

I've read two pieces of information lately that couldn't be more different, and yet they both got me thinking about the benefits of what I call a "distributed PMO."

First, as I mentioned last week, I had read about Ken Kizer's magnificent transformation of the formerly abysmal Veteran's Health Administration (a poorly run group of hospitals mired in government hierarchy and bureaucracy). He established an network of regional "hubs" (what he called Virtual Integrated Services Networks, or VISNs - pronounced "visions"). Each VISN was itself a network of partnerships, associations, alliances, hospitals, etc. that worked together for the good of the customer.

The VISNs had the benefits of standardized quality with local presence. Decision-making was moved from Washington HQ to the VISNs, who were closer to the action than Washington HQ could ever be.

The role of headquarters became one of support, guiding principles, consulting advise, information services, and change leadership. Headquarters drives behaviors that benefit the overall structure.

Forms and approvals were reduced to a bare minimum. A relentless focus on the customer/patient (one of my battle cries, as most of you know) now guides all decisions and research.

If this isn't a good model for a PMO, I don't know what is. If project managers and functional experts (each who rely on one another for success) operated in various "regions" and/or functions (close to the action), and the PMO's role were to provide (and I repeat from above) support, guiding principles, consulting advise, information services, and change leadership, more PMOs would become a valued and integrated part of their organization.

And if the focus were on reducing forms and bureaucracy, helping project teams be successful, and improving the customer experience (as opposed to an internal focus on merely schedule and budget metrics), PMOs might find themselves more popular as well.

Incidentally, this also happens to mirror the Toyota organizational model.

The idea of a distributed, integrated network isn't unique to business. It even happens in nature (here's where the strange part comes in). I was reading about a giant sea creature, larger than a blue whale, called a Giant Siphonophore (Praya sp.). The creature (yes, this is true, folks) runs 130 feet long and is actually made up of many other life forms, each having its own specialized role that works to service the whole entity, yet is unable to exist on its own. In other words, the Giant Siphonophore is a "colonial life form." As I read this, I was again reminded of the concept of a virtual, yet integrated network.

Yes, I actually make these odd connections, but ideas can come from anywhere. By the way, the creature can be seen in the IMAX film, The Living Sea (available on DVD). Here's more info on the colonial nature of the Giant Siphonophore and it mutually dependent parts. Food for thought.

Is the Role of the Project Manager in Jeopardy? - An Editorial

A few weeks ago, I posted a blog about the new Program Management credential from PMI. In it, I referenced PMI's definition of a program manager vs. project manager in their FAQ page.

A project manager, according to PMI, has the following responsibilities (I've put some of the key points that jumped out at me in bold):

• Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project
• Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources
• Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

A program manager, according to PMI, has the following responsibilities (again, I've bolded the key points):

Under minimal supervision, program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.

Clearly, a program manager must be closely tied to the strategic goals and benefits, monitor the program accordingly, and have a strong connection to senior management. And I also feel that the new credential seems on the surface to set the bar appropriately high.

But I can't help but feel that, in contrast, the PMP credential is losing steam. First, there are myriad organizations virtually guaranteeing an "instant-PMP" after a crash course and some tweaking of one's background experience (although PMI is now doing audits of work experience).

Second, a project manager must, in many cases, go beyond the PMP/tactical focus and possess the same traits and skills that PMI has designated as requirements of a program manager, especially in the case of an enterprise and/or global project, such as a business transformation effort. I realize PMI's role definitions are a way to differentiate and justify the new certification and I suppose one could organize their effort into a "program" to qualify for that certtification, but in these changing times (and with greater challenges for project managers), I think PMI needs to evaluate and revamp the PMP certification as well.

When I do presentations on principle-based leadership training, I have a slide where I present what I call "The PM Challenge." I present it as a boxing match. In one corner, we have a project manager, armed with MS/Project and the PMBOK, but lacking:

• Business Acumen
• Leadership Skills
• Conflict Management Skills
• Negotiation Skills
• Presentation Skills
• Communication Skills
• Strategic Intuition

In the other corner, we have the "challenger," represented by "the project," with the following characteristics:

• Global, virtual team
• Complex technology
• Complex change
• Multiple vendors
• Offshore resources
• Conflicting Stakeholders
• Scrutinizing Executives

Such a project manager, without the appropriate leadership and soft skills, doesn't stand a chance. Wouldn't a person with the skills PMI describes as a "program manager" be more apt to have success?

In the latest PM Network magazine from PMI, there are not one, but TWO articles that illustrate this point. One is titled "Project Management 2.0: Project Management is at a Crossroads," by Peter Fretty. The other is titled "No Limits," by Marcia Jedd, and talks about what project managers must do to crash through the glass ceiling and elevate it from the tactical trenches.

Perhaps a start would be to take a new view of project management beyond just "executing to a set of requirements to deliver on-time and on-budget." The current tactical focus might explain the consistent failure rates of projects. One problem is that PMI has traditionally "followed common good practices in the field," which of course is what a standard is supposed to do. The problem is that common practices have brought common results, which aren't all that good. Time for an upheaval. Perhaps they need a section, apart from the "standard" itself, for "new frontiers in project management," which could outline those who are breaking the mold with good results.

I'd be interested in others' thoughts on this topic. Who knows---It just might help drive requirements for the next version of the PMBOK and/or PMP credential.

PMO Success Story: A.G. Edwards Case Study

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used Primavera for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in Primavera).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful, and are philosophically aligned with the Service Oriented-Project Management (SOPM) model I've been developing. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

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

Team Fun on the Cheap

Is your team suffering from infighting or poor morale?
Do you need a different way to celebrate a milestone on the cheap?

Consider the potluck. Dictionary.com defines the potluck as: A meal at which each guest brings food that is then shared by all.




Although it might be a bit of work for the project management team, organizing a potluck is a cheap way to get the team together. It is especially fun when there are international team members who can showcase food from their respective cultures.

Some tips for organizing your potluck include:

• Schedule it for a Monday. This gives people time to cook over the weekend.
• Create a sign-up spreadsheet with categories like appetizers, entrees, etc., so people can attempt to even the spread.
• For those folks who don't like to cook or don't have time, offer the "bring a staple" option. Every potluck needs plates, utensils, napkins, drinks, table cloths, a clean-up crew, etc. I usually use the "fastest timestamp wins" method for these.
• Book a large enough conference room for several hours around lunch time OR
• If you have a huge team, consider also having people bring in breakfast items (then extend that conference room booking)
• Consider creating a "party favor" for all project team members. We had mugs made with our project name and then filled them with an assortment of goodies in nice party plastic bags (pretzels, candies, nuts, etc.). This was also a team building opportunity because people shared well after the event.

What other ideas do you have for team building events? Let us know!

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

Microsoft Vista Project Management: Scope or Schedule Management ...

Microsoft struggles with Vista project management. Working the triple constraint, Microsoft adjusts scope and schedule - and, likely, costs are increasing as well. Article explores options for improvement, including ruthless schedule management, better requirements management, etc. ...

... "With Vista, Microsoft originally hoped to make major changes to the underlying code, adding in a new file storage mechanism called WinFS, along with all-new graphics and communications methods. It eventually had to pull out WinFS entirely and scale back several other architectural changes in order to make the project more manageable. " ...

Microsoft Vista Project Management: Scope or Schedule Management : Clouds over Redmond: Via ZDNet Australia ...

ERP Project: Keep Eye on Details ...

Firm publishes report on approach to challenging ERP business transformation projects. Current marketplace conditions are impacting the quality of ERP implementation talent even in the context of a strong methodology. This requires the client company to pay close attention to the project details. Be on the look-out for: Lack of transparency, limited bottoms-up planning to complement the top-down methodology, no iterim integrations with legacy systems to bridge gaps during the implementation, and missing current state analysis.

... "Based on its work helping numerous companies pull errant ERP projects back on course, DiamondCluster has identified circumstances that endanger projects and offers specific steps that can keep companies moving in the right direction. " ...

ERP Project: Keep Eye on Details: Via DiamondCluster: Red Flags Can Signal That ERP Integrators Are Off Course According to New DiamondCluster Report: Studies Show Many ERP Projects Still Run Significantly Over Budget and Behind Schedule. New DiamondCluster Report Explains Why and Offers Advice to Keep Efforts on Track ...

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.