Author: Neville Turbit

Read Part Two…

Overview

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.

1. Outcome from the Project

How will the project impact the organisation when it is completed?

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.

Questions

Here are some other questions that help uncover information:

• Are the people who will be impacted by the system going to be surprised when it is implemented? (In other words, do we need to manage expectations)
• How are you going to ensure the system does not dictate or perpetuate inefficient practices?
• What will people miss when their current process is changed?
• What impacts will be felt outside the company?
• How will I see a difference to my business area?
• How will I know it has been a successful result? (Beware of an answer that focuses on the on time/on budget project completion. The team may be too internally focused)

Example:

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.

2. Resourcing the Project

What arrangements are in place for resourcing the project?

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.

Questions

• If contractors are to be employed, how easy is it to get people with the necessary skills?
• What is the likely lead-time? How will this affect the schedule?
• Do you have agreement to get specific business resources at specific times?
• Do you feel the business people have the necessary skills to provide input?
• Will people with new skills be required after the project to support the new system?
• What arrangements are in place to get cross organisational support? (Assuming other business areas are involved)
• Where are the potential resource weaknesses?
• Who are the key players that, if they were to leave the project, would cause most pain?

Example:

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.

3. Monitoring the Project

How will we know on a week to week basis if we are on track?

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:

• Are we on schedule?
• Have we spent what we said we would spend?
• Do we still think we have enough money to complete the project?

Questions

In addition, the sponsor should ask:

• Who will be alerted if there are serious issues?
• When will they be alerted?
• Is there a gating process to approve the next lump of expenditure?
• What criteria will be used to get through the gate?
• Are there any issues in how finances are tracked?

Example

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.

4. Risky areas in the Project

What are the risky areas in the project?

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?

Questions

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.

• If there were a potential single point of failure, what would that be?
• Would you be surprised to uncover any new and substantial risks?
• How often will a risk review be undertaken?
• Who will be involved in that review?
• Will it identify business risks as well as project risks?
• Who will be responsible for managing the business risks?
• Will there be a contingency plan if the project should fail at some point?
• Why is the risky area required?

Example:

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.

5. Project Options

What other options have been looked at for this project?

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?

• Lower cost to deliver
• Faster delivery
• Better integration with other systems
• Lower maintenance costs
• Easier to scale up at a later date

Questions

Questions include:

• Do we need to do this project at all? What will happen if we don’t do it?
• Why is the deadline important? What happens if we don’t meet the deadline?
• Should we consider a package rather than build a solution (or vice versa)? Why?
• Can we change the way it is delivered? For example, rather than implement all at once, can it be delivered incrementally?
• Can it be rolled out to only some users or some customers?
• Can it be tested by running in parallel with our existing system?

Example:

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:

• Do we have experience in this technology?
• Is it stable or is it new and evolving?
• How easy is it to get people who know the technology?
• Can we support it in the future in-house?
• What is our migration path out of this technology if it does become a dead end technology?
• What sort of upgrades are we likely to have forced upon us over the next 5 or 10 years?

6. Project Goals and Scope

What do you see as the goals of the project and what is in and out of scope?

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?

Questions

Ask questions such as:

• How does this contribute to the achievement of goals?
• If we didn’t do this work, how would the goals be impacted?
• Is there anything that needs to be done to create a foundation for this project such as installing new infrastructure, or upgrading PCs?
• What concerns to you have regarding areas where the scope is not clear?
• If you were to get a blow out in the scope, where is it likely to happen?

Example:

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.

Summary

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.

Copyright Project Perfect