The Numbers Against the Business

Project management is full of statistical numbers. Enough to make an economist’s head spine. We use task tracking, risk analysis, P-Value, Binomial Distribution, Sigma, and Poisson Distribution, just to provide some simple explanation of how a project can affect a business. But to the average business individual, these numbers are almost meaningless.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man."
George Bernard Shaw

While working at an organization I had to implement a large database application. This application was a Customer Relationship Management (CRM) application. The project started off normally with the Request for Information process and then the Request for Proposal process. Staff even had their input into the application selection. The project was well defined and had executive support.

Using standard project management methodology, a project summary was drawn up. It included the usual things; objectives, goals, risks and critical success factors. Then the other usual documentation of the high level project schedule, resource needs, communication structure and risk analysis. The project sponsor thought that the risk analysis was over kill documentation. This was due to the “expected level of commitment by all of the executive team” and that the project was to be successful. Strategic plans were being developed that would need the application as the main tool to accomplishing future goals.

The risk analysis was a mathematical calculation of the “what-ifs” of the organization. Due to the history of the organization having large scale projects failing in the past, I decided to include this brightly colored picture. Yes, I put red, yellow, green columns on each measured risk point. This allowed me to have the visual representation of; “Things are fine”, “Things are a little off”, (to the most important) “Hey we have a problem”.

As the project started to get going I needed to fully understand the extent of operational changes that the new system would create. I chose to perform a mapping of the existing business processes. I think this was the first sign that things were going to be difficult. When I started working with staff on how they did their jobs it was like I was demonstrating something totally new. Using a Visio and a note taker we mapped out down to the smallest detail what everyone in the organization did. It was eye opening for everyone and a great team building exercise. The down side was that this was the first time staff recognized that they actually did something repeatable.

Before, the general thought was that for most everything they did each day was always something new. They never thought of themselves as needed to repeat how they accomplished something last month and do it again. This created a sense of information overload for the staff. Then resistance to the idea of the new system, as their newly discovered information showed them they had a working set of processes. So a basic project management tool for creating a successful project turned into an addition to the risk assessment in a negative way.

Then a wave of attrition came through the organization. Now every organization goes through periods of roll-over staff and this is most of the time far outside the control of any single project. Now the new system project was not the only factor; political change in one office and a naturally high attrition rate in the industry also were in play. However, I found that several key individuals left as they could envision how the project of the new system would alter their jobs so much that they rejected being apart of the whole thing. The attrition reached over 20% of the organization and I went back to the risk analysis far more seriously.

The fist measurement of project failure was around 3%, and then moved to 7% to 10% when the business process mapping was completed. Once the attrition started, the risk of failure jumped and kept pace with the organizations attrition rate. I brought my analysis to the project sponsor and made it very clear that the rest of the executive team needed to know that things are looking very bad. The sponsor offered to reduce the scope dramatically in order to not just complete the project but have the scheduled roll-out done on time. The only way I thought that this could be accomplished is if we reduced the scope to 1/3 of the project.

So with a much reduced scope the project continued. We still had the same rollout in 4 months, but this time with a team that only comprised of areas of the organization not being affected by attrition. Problem averted, right? Well we found a kind on flaw in the application. Not really a flaw, more like, well, Vapor Ware.

“Vapor Ware” is that technical term for an application that is sold as existing and functioning, when in reality the vendor has to build it. Many portions of the application needed “custom configurations” in lieu of the typical “setup configurations” in most applications. This was the gold-calf for the vendor where each implementation requires billable “custom configuration” just to setup the application to function. No mention of this by the vendor, referred customers or the newly created users group.

Although the scope has now been reduced, the amount of work and tasks to be completed tripled. This basically washed out any chance of reducing the risk to the project. So we marched forward. As you have guessed; support for the project wavered; demand for change in project management and project sponsorship occurred; demand for financial compensation from the vendor ensued; the whole host of things that you don’t want to see happen to a project, including staff not involved in the project joining in with the poking fun jokes about the application.

So was the project successful? By the numbers, the reduced scope was implemented and the application is functional. By the numbers, the number of staff intended to use the application in the reduced scope is using the application. By the numbers, the budget ran over by twice the amount of the original scoped project. By the business, those using the application are slowly becoming satisfied with the application. By the business, no area of the organization is able to identify where their repeatable business processes are used in the system because they still do not believe they have “business processes”.

Is this a draw?

Notice: posts will have the highlights of projects that I have been apart of or have managed. Some of these examples have been fictionalized to make certain points. The examples are not a complete rendering of all the events of any project, example or actual event. Nor are they intended to be a factual accounting of events in a project, example or actual event. The examples of projects are to inspire and provoke thought on how anyone of us would have handled the situation. My intention is to highlight those "moments" where doing things one way or another might have changed the end of the story. This is done in an open and learning format where I hope we can all continue to learn together.