 |
|
 |
|
|
|
 |
|
|
| Home | - | White Paper Index |
Helping Business Managers Evaluate a Potential Project |
|
Neville Turbit - Project Perfect |
First published May 05 |
Rating |
|
Also see our White Paper on Evaluating an Existing Project |
 |
I recently had a discussion with a Senior Business Manager regarding evaluating potential IT projects. He had recently been bitten by a project that was poorly managed and wasted considerable time and money before delivering anything. What it did deliver was not necessarily the best solution. He expressed his concern that he was not a technical person, and when confronted with a new project, did not know which rock to turn over to see if it was being properly set up. This article sets out six questions a Senior Business Manager should address before a project is started. It assumes of course, there are resources involved in the project, and there is some understanding of what is involved. |
The questions are open ended, and a simple answer should ring warning bells. Almost all projects have a complex answer to each of these questions and they need to be talked through. The ideal way to discuss these questions is to have the key players sit around a table and discuss each of the questions in turn looking for something that may not have been taken into consideration. Included in the group should be senior technical and business people.
The purpose of this question is to look at who will be impacted, and the likely changes that will need to be catered for. It is not just about the IT system. It is about the changes to business processes, personnel, customers, physical locations, skills required and many other aspects.
Here are some other questions that help uncover information:
A project to create a new billing program will impact customers. How are they being involved in the project and their needs met? One project I heard about resulted in a 10 digit delivery number being generated. Their major customer could only handle 8 digits. Nobody spoke to the customer until it was too late. Deliveries could not be booked in and were consequently sent back to the supplier warehouse. If the customer had been involved earlier, there is a good chance the problem would have been picked up.
One of the primary failure points in projects is the availability of resources. The concept of executive support does not always run to specifics such as providing three people to do testing full time for two weeks.
The project manager should have identifies what resources are required, and negotiated the people’s availability. This includes internal and external resources.
A project I reviewed was approved in December and started looking for a key resource just prior to Christmas. As you would expect, it was February before a resource was found and started. Two months were lost waiting for the resource to come on board.
The project plan should be constructed with regular milestones. More than two weeks between milestones should ring alarm bells. The project manager should be able to provide a set of milestones that will enable the sponsor to see within a few weeks if the schedule starts to slip.
Similarly, reporting financially should be against an agreed cash flow for the project, not against the total budget. There should also be regular estimates provided to the Sponsor of the cost to complete. In other words:
In addition, the sponsor should ask:
A project to roll out Windows XP to a number of branches was presented to the GM of the area. What was not known at the time was that some of the PC’s needed to be replaced because they were not capable of running XP. Because the rollout was not a consistent number of upgrades each month, the Sponsor believed it was on track until the 4 th month of a 6 month program. By that stage, the budget was 80% gone, and only 60% of the PC’s had been upgraded rather than the planned 75%. The PM hoped to catch up in the last few months, but waited until the 4 th month to tell the Sponsor that he needed more money.
He was behind schedule and over budget. If he had milestones that indicated that by the end of month one he would have 15% complete, and his cash flow reflected the milestones, it would have been evident from the start that the schedule was slipping, and the expenditure was creeping ahead.
There is a difference between identified risks, and risky areas. When the discussion is taking place, there may not have been a comprehensive risk assessment study undertaken. What the question focuses on is, given the nature of the project, where are the risky parts. Is it resources? Is it technology? Is it unknown data quality?
Once identified, the risky areas can be discussed and perhaps further work undertaken to see if there are ways in which the risky areas can be catered for.
A life insurance company was converting a small number of old policies to a new system. One risky area was the lack of people who understood the rules surrounding policies that were over 20 years old. The company had changed hands a number of times and in the merging of different departments, knowledge had been lost. Documentation was patchy.
Once identified, it became a separate exercise for the Actuaries to look at these old policies to identify what documentation existed. In the end, it was decided to buy out the old policies, or offer conversion to a newer policy at a rate that was beneficial to the policy holder. It was going to be too hard to try and reconstruct the policy rules by reverse engineering the old Cobol programs. The project was significantly scaled back, and only a few policies converted. The others were transferred or bought out.
By exploring what is risky about the project, it is possible for the Sponsor to get an understanding of where to watch, or even if there is another solution to a potential problem.
Beware the project manager who immediately starts talking about the solution in a technology sense.
“Of course we will use ASP.Net running off an Oracle database and use a mix of C# and VB.”
The question should be
“What other options have you looked at and why is this, the best option?”
For this reason, the business manager needs to have senior technical support in the room. It should not just be the Project Manager or Developer who decide because it is a variety of technology they are familiar with, or would like to play with.
Basically it should be the business who decides the requirements and IT who decide the best technology. IT should however be able to justify it in terms business can understand. For example, will the technology result in?
Questions include:
An interim solution for an insurance company to handle customer queries was built using a technology called “Mantis”. Like most people I had not heard of it before, or since. The main reason was that we had a programmer who had taught himself the language and was looking for a place to practice.
Six months later, we had a fully operating system that did the job. Then the developer left the organisation. The results were predictable. We could find nobody to make changes, and ended up employing the ex-developer on weekends to add bits and pieces to it. In the end, it cost considerably more than it should because of the fact nobody could support it. Mantis turned into a dead end technology and the application had to be re-written much sooner than anticipated.
The questions to ask about these technologies are things like:
All this had probably been documented but it is worth asking people to explain verbatim what they see the project is trying to achieve. If they can only explain the goals in terms that came straight from the business case, they probably don’t really understand what the project is all about.
The second part of the question is really about how you translate the goals into deliverables. How do you deliver something that will achieve those goals? Conversely, what are the things that may be on the periphery of the project that do not contribute to the goals and should not be in the project?
Ask questions such as:
I was asked to review a project that involved a billing system for a government department. When I held a workshop which involved both the Sponsor and project team, I asked the Project Manager to articulate what she thought the project was trying to achieve. To condense the story, the PM talked about an efficient payment processing facility for sub-contractors. The Sponsor was astounded. She saw it primarily as a way to monitor the cost of individual sub-contractors so that higher charging sub-contractors could have their rates reduced when contracts were re-negotiated. She was quite happy with the efficiency of the existing system but couldn’t get comparative information.
For any Senior Business Manager evaluating a project should not be an impossible task. Most problems are not technical. They are usually related to either not clearly understanding what is to be built, or problems with the people involved (or not involved as the case may be).
The Project Manager should be thankful to have the opportunity to gain a shared understanding with the Sponsor as to what the project is trying to achieve, and what needs to be done to reach those goals. She or he should also be pleased to get agreement about the resources assigned to the project. If the potential problems can be addressed early, there is less chance of something going off the track as the project progresses.
The Sponsor is looking to find out if the project is sensible, and where they should focus during the project. This includes the risky areas, the milestones and the cash flow in the project. They also want to be comfortable that options have been explored and the path proposed is the best option.
A discussion exploring these six questions can bring the Sponsor and the Project Team closer together and ensure they understand the mutual obligations and commitment required.
To date, 56 people have rated this article. The average rating is 4.20 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed. |
|
|||||||||||||||||||||||||||||||||||
