The Irony of Project Management: the practitioner’s view

I was recently hired by an important financial institution from Canada to help them assess their strategy for a transition to a new a version of their content management software. Content management software is a portion of an imaging system that allows users to scan documents, index an image, retrieve and view image documents.

The current version at the financial institution is a Windows based GUI (graphical application based). The proposed version was totally web based. After a business review that included a field study and cognitive analysis, I discovered that both the current and the new software didn’t meet the business needs. In fact the current version required lot of manual entries and was highly error prone while the new version would not address those issues and would, in addition, require three times more user action.

I soon made my client aware of this. The project manager, who is from the information technology department, reacted by saying the project scope is to make the transition, respect deadlines and budget. Meaning he does not want to change the plan. Information technology department even contested my findings and required me to demonstrate the facts again. After revisiting my findings they realized that the situation was even worst than they expected it. In the end, the financial institution followed my recommendations because the facts were rock solid and we found a solution that would integrate existing technology already in use at the financial institution.

Sounds familiar? Many IT (Information technology) projects are planned and scoped before analysis or field study is done. In many instances, the justification is a technology replacement or and upgrade. Over the last twenty years I devoted my consulting practice on project turnaround and I encountered hundreds of similar situations.
Last year I attended a three day PMI (Project Management Institute) training camp. What amazed me the most was the widespread acceptance by the PMI community of the irony of planning and estimation for software projects.
Here is the problem:

To estimate a project, you must first know the amount of work required to complete the project. To build two (2) kms of road will require twice as much work than building one (1) km.
In a software project, the amount of work is defined by what (the functions) you will build. You will have a good idea of the functions you will build after the functional specification phase. Since the functional specification is usually done after the planning and estimation, you get the information you need to estimate the project after the project is started. It is a bit like if you have to plan and budget the medical treatment before the diagnostic is done.

I can assure you that in physics, my previous career, you would get fired or put aside fairly fast if you come up with something like this.

What is more, estimation at the planning stage is guesswork. In PMI methodology, they mention arcane techniques such a point of function method or historical data or some other combinations but again, this is, in my view, a sophisticated cover up for guesswork. Yes, there are calculation methods but the input assumptions are based on human judgment (guess). Those judgments vary from one person to another. Often, the estimator does not have any ideas about the business and operations. For example, in the Government of Quebec, software architects estimate after meeting user’s representatives that previously met business analysts who never met end-users.

Typically, once estimations are done, budget, scope and timetables are established. The board approves the budget, people are hired and project execution begins. If you discover in the course of the project that real business needs differ from what you planned, the story above is repeated. The project manager will tell you it is out of scope. Or he might say your new findings could be filed as change at the end of the project. Remember, he is hired to execute the plan even if proven wrong. Isn’t he?

There are solutions:

1. Do you ask yourself if the application you are using (email, office application etc) is in Java, PHP, C Sharp, etc? Most of us will answer “I don’t care”. In fact, 100% of the user experience (UX) is provided by the user interface (UI). So why not start the project by the end. Why not design and test the user interface before the project is established and a budget is set. Then you will know what to build.
2. Look at other industries, such as automotive or aerospace. They all start by verifying their biggest risks first. When Airbus or Boeing want to develop a new airplane, they build a large-scale model, display it at Bourget salon and take orders even if the plane does not exist. If there is not enough order, they will cancel the project. Car manufacturers, design clay models, present those models in a show room to verify if the client will buy it. Then they will plan production. So both automotive and aerospace start by the end.
3. Remove red tape and bureaucracy. Allow direct communication between developers and users
4. Invest in continuous business analysis processes where field study (ethnographic study) is part of the culture. To my knowledge, the best approach to do business analysis is the cognitive approach.
5. Budget business analysis and diagnosis throughout the operation on a continuous basis.
6. When executing verify risk by simulation, experimentation or calculation.
7. Allow information to circulate though project by keeping project size small