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:
- 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.
- 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.
- Remove red tape and bureaucracy. Allow direct communication between developers and users
- 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.
- Budget business analysis and diagnosis throughout the operation on a continuous basis.
- When executing verify risk by simulation, experimentation or calculation.
- Allow information to circulate though project by keeping project size small
It looks like another client saved considerable pain by having been lucky enough to hire someone willing to speak out rather than just going along with the brief. I am often concerned by the extent to which people edit what they say before it has even been spoken. That way people become accustomed to continuing down a narrow path failing to see opportunities all around, or failing to undertake the due diligence needed to move beyond satisfactory to excellent.
…Geoff
Very good and very revealing of the inertia within IT departments!
How typical!!!
Good article…
I often see this kind of situations… Project management is still in many organizations an “accidental” profession/discipline… I’m pretty sure this PM never followed a practical PM course… It’s very common.
Here are the key success factors (by priority) in project management:
1- End-user involvement
2- Top Management support/buy-in
3- Clear business objectives (ouchhhh)
4- Proper planning
5- Realistic expectations (t/$)
6- Competent team/PM
I agree with Mr. Gilbert. PMI in itself is not responsible for this situation. On the other hand, the real success factors is in the execution, the ”How?”
I will take golf as example. On paper, the strategy is quite simple.
1. You use the driver for driving
2. You make approaches with the appropriate iron
3. You finish on the green with the potter
While the strategy is simple, in Golf, the execution is the real challenge. It takes years of practice, reading, lessons and hard work to be just good.
Similarly event if the strategy in PM is simple, the real challenge in getting end-user involvement where the goal is to ensure proper user’s requirements is the execution. Getting the exact user’s requirement, takes years of practice, training and hard work in human factors. In human factors (cognitive ergonomics), the main techniques to get proper use requirement ( the putter) is the task analysis. My new staff with proper training (usually PH.D) become good at it after 10 years of practice and coaching.
By the way, most people in the (IT) industry are not aware of cognitive ergonomics. They plan for a high degree of uncertainties in user’s requirements.
Getting clear business objectives is event a bigger challenge. What is the competitive environment, what is the internal current situation, what are the business goals. It takes in my view a minimum of 10 to 15 years of consulting practice and many skills. An even bigger challenge is how to communicate those findings.
An son on. I think I will have to write a complete post on the key success factors.
Francois
NubyErrobre
af5d
voxExpots
awpg