After a business review that included a field study and cognitive task analysis, it was found that the new software require three times more user action. The project manager reacted by saying the project scope is to make the transition, respect deadlines and budget. Meaning he does not want to change the plan.
After reviewing the findings again, they realized that the situation was even worst than they expected it. In the end, the client followed our recommendations because the facts were rock solid and we found a solution that would integrate existing technology already in use at the financial institution.
Many IT (Information technology) projects are planned and scoped before need analysis or field study are done. Over the last twenty years of project turnaround and we encountered hundreds of similar situations.
Last year we attended a three day PMI (Project Management Institute) training camp. What amazed us 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 our 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, 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?