successful projects

As a management and technology consultant, I get parachuted into projects where stakeholders are screaming for help.

The challenge is to refine the process of taking the diagnostics. When a project is recognizably in trouble, it has exceeded a threshold of constraints. So in order to salvage the project, we will have to assess the current state, the desired state, and propose a roadmap of accelerated performance in order to get back on track.

I've used gap assessments based on different project methodologies to establish the baseline and reset the focus on the end goal. One logical step in the process comes from Six Sigma techniques. An affinity diagram shows a pathway that aggragates all of the negative symptoms into a root cause.

Interestingly, every one of these affinity diagrams have led to the same root causes. I tend to skip this step formally unless the participation and presentation of the team is required for buy-in into the solutions. As we assess failing projects, the affinity diagrams always point to the same three things:

• poor mgmt
• lack of budget
• lack of resources
  

What is a successful project?
A project by definition is a temporary and unique task and must conclude. A successful product is one that simply delivers.
A second layer of success is to analyze the results within the Triple Constraints (time, cost, scope). Each of these primary constraints are weighted uniquely on each project. A first-to-market product will be time critical, while a commoditized product will be very cost sensitive.
A third layer of project performance taught by PMI is the quality, risk, and customer satisfaction.

Roadmap
I have found this to be an invaluable presentation tool. Clients want to see a linear and logical sequence of corrections and events that will bring the project to completion in the most efficient way.

While the solutions and steps vary based on the effort, two solutions are common:

1. an experienced PM can re-scope the work to align with the existing resources, then manage to maintain the resources for a short duration, then raise new resources in the bullpen for future projects.

2. a true systems engineer can help a PM to search for a solution that is within the project constraints, i.e. redefine the technical scope, reduce the development risk, or simplify the integration.

The funny thing about an unhealthy, disfunctional project is that the team believes that it is operating normally. It can be easy for an outsider to audit processes and deliverables to see a different perspective. We use the "frog in a pot of boiling water" analogy. The project is like pot of boiling water. The team has acclamated to the chaotic state that built up over time. If the team jumped into the middle of the project with all of their senses in place, they would immediately jump right out of the pot.

After a few years of assessing unhealthy projects, the first clue in finding a bad project is when the team's primary objective and complaint is for more people. Fred Brooks' 'Mythical Man-Month' explains how adding more resources will never increase efficiency.

In reality, the only way to pull off the miracle finishes is to remove all non-essential members and apply the most senior resources. There just isn't time for extra communication channels, overhead, and training, when the project becomes at risk of cancellation.