Author: Neville Turbit

Overview- Starting a Project

This white paper covers what you need to do to start a project – sometimes called project initiation. It starts when someone says “We should put a project together”, and ends when you sit down to write a project charter or project definition. Many people ignore this activity and just jump in and start doing things. Unfortunately, they often waste time spinning wheels and going nowhere, taking off in the wrong direction or miss issues that later sink the project.

Why Initiate a Project

1. Key Stakeholders

Very often, projects are started because they are the pet cause of an individual. It sometimes happens that the individual is either not one of the key stakeholders, or alternatively is only one of many key stakeholders.

A project I once worked on was driven by a State Sales Manager. It was to better manage point of sale material. She was frustrated that her sales team were always running out of materials, or materials were never available in sufficient quantities. When I started talking to people, it was evident that another key stakeholder was the Warehouse Manager who was responsible for inventory. When I talked with him he also identified the Marketing Director who was responsible for producing the material; the Distribution Manager who was responsible for storage in general; the Transport Manager who moved the stock around, and the Purchasing Manager who was responsible for buying the material. All needed to buy into the project for it to have any chance of success.

The point of identifying the key stakeholders is that had I let the Sales Manager drive the project, we would have run into a number of brick walls dealing with people who the Sales Manager had no authority over, and who may not have understood her particular problem.

2. Perspectives of the Project

It is called lining up all the ducks. It means getting everyone to agree as to what the business problem really is. In the above example:

• The Sales Manager had too little stock
• The Warehouse Manager had too much stock – most of it outdated
• The Purchasing Manager was looking for a few large orders where he could get a lower unit cost rather than smaller more flexible orders
• The Marketing Manager thought it was a smokescreen because he had been criticising the sales team for being too lazy to use point of sale material
• The Transport Manager was looking for less frequent deliveries to restock the warehouses
• The Distribution Manager thought everything was fine and didn’t understand why the project had been started.

In the end, I had to get them all in the room to talk about their particular issues, and reach some consensus as to what we were trying to achieve. In fact we managed to make some business process changes that solved many of the problems.

• The Marketing Manager agreed to produce an obsolete materials list so that old stock could be dumped
• The Purchasing Manager agreed to negotiating direct from printer delivery schedule rather than store in a central warehouse and double handle everything for branches
• The Sales Manager agreed to produce forward estimates of requirements for the Warehouse Manager
• Branches circulated their stock levels on a weekly basis to enable inter-branch transfers to take place.

In the end, the project was severely downgraded in importance, and business process change was able to considerably lessen the impact of the business problem.

3. Committing Resources to a Program

On another project I interviewed a key stakeholder. The conversation went something like this:

Q. Do you see yourself as a part of the project?

A. A critical part.

Q. Who from your area will be available to work on the project?

A. My supervisor will be able to spend a few hours a week.

Q. What about you?

A. Don’t expect any of my time. I have too many other things to do.

Q. So will the Supervisor be able to make decisions on your behalf?

A. Absolutely not!

I thought at the time

“Here is a problem that could cause the project to fail. Thank heavens we found it now.”

Imagine getting into the project to find a key player who didn’t want to play. Not only that, but our main source of information was someone we could only get a few hours a week from, and who was not trusted to make decisions.

My subsequent comments were that my recommendation to the Sponsor would be that, the project was postponed until the Manager (who had just told me how critical he was), could find the time to participate. Since his Supervisor could not actually make decisions it was a waste of everyone else’s time for the supervisor to participate. On hearing this it occurred to this particular Manager that in fact they could make themselves available, and that the Supervisor could in fact make many of the decisions on procedural matters.

It is critical to the success of the project that key decision makers and influencers can be engaged. If they can’t, the project should not start. A situation like this needs to be escalated to the Sponsor and should be presented in a manner that makes it obvious the success of the project (which will be a reflection on the Sponsor) is in jeopardy unless key stakeholders provide the time available.

It is also important to establish if their staff will be available. Take testing as an example. If you ask

“Will staff will be available for testing?”

the answer will probably be “Yes”. If you phrase it

“In October or November, we will be doing testing which will require at least two, and possibly four staff from your area to be available for three weeks. Can you give a commitment that those staff will be available?”

it puts a different complexion on the question. If the answer is “No”, then at least you have time to address the situation. It may require the Sponsor making arrangements for replacement staff to be available; it might involve slowing down the testing to take 6 weeks instead of 3; it might even mean canceling the project. Better to know now.

4. Expectations of the Outcome

The fourth question is about expectations of the outcome. I was asked to review a project for a stockbroking organisation that appeared to have stalled. The project was to deliver a system that would allow clients to carry out online transactions on their portfolios. To cut a long story short, the two key stakeholders were the Financial Manager and the Marketing Director. The Marketing Director wanted ‘bells and whistles’. He wanted to gain a competitive advantage by providing a broad range of options for the clients to use. The Financial Manager wanted no ‘bells and whistles’. He wanted a simple process that had little variation and was easier to manage.

The winners were the company building the system. They would develop a piece of the system and bring a prototype in to show the Finance area. Finance would declare it too complex and send them away to make it less comprehensive. A few weeks later they would show the Marketing area the simple solution. They would declare it too basic and tell the developers to make it bigger and better with lots more options. Another variation – another bill. No wonder it was going nowhere.

My recommendation was for the CEO to step in and negotiate the final product between his two managers. After he had carried out the exercise, he said to me

“How did it happen? How did it get so far before we recognized the problem? How much money have we wasted reworking the solution because we didn’t agree where we were going?”

I didn’t have an answer for him other than to say

“Why didn’t someone look at this before you started?”

Identifying differences in expectations must happen before a project can move forward. Unless everyone agrees where you are going, the best you can hope for is that you will have only some happy travelers. What usually happens is you end up with some patched up compromise and no happy travelers.

How to Initiate a Project

Here are some steps you can undertake to properly initiate a project.

Identify the likely Sponsor

Usually the Sponsor is evident but it may not be so. The Sponsor needs to be committed to the project rather than just nominated to the position. If the Sponsor does not believe strongly in the project, what chance do you have for support when the going gets tough?

Identify the Key Stakeholders

With the help of the Sponsor identify who else is a stakeholder. Don’t accept ruling a key stakeholder out because they don’t support the project. Sometimes a person outside the project can sink the project more effectively than someone inside the project. It is better to understand why they are opposed to the project before you start.

Prepare a Questionnaire

Look at the four questions above, and put down some questions you would like to ask people about the project. Here are a few:

• Where do you think the project is up to at the moment?
• What do you expect will change in your area when the project is complete?
• What are the biggest hurdles we need to overcome?
• What differences of opinion exist regarding the project?
• What is the business problem the project is trying to address?
• Who will authorise requirements, changes etc.?
• What areas of the organisation are opposed to this project and why?
• What are the biggest risks to the project?
• Is there anything significant about the completion date?
• In your eyes, how will you judge the project as a success?

Interview the Key Stakeholders

Book half an hour to an hour with key stakeholders and work through the questions. At this stage you are information gathering. Don’t try to resolve differences or you will not get through the interview. You also risk getting the person into an argumentative mood and they may be less than forthcoming. Remember to ask about who the other key stakeholders are. It is not unusual to unearth a few stakeholders you didn’t know about. After you finish, document the discussion.

Identify & Resolve Problems

Looking across all the interviews identify conflicts and differences. Make a list of these issues and discuss them with the Sponsor. They need to be either resolved prior to you developing a project charter, or the impact built into the project charter.

If a key business area says they will not have anyone available to work on the project for two months and you can’t change their mind, build a project plan that delays the project two months. If the Sponsor disagrees, the Sponsor has to convince the business area to make people available earlier.

Conclusion

The cause of many project failures can be traced back to the early days of the project. What eventually causes it to come tumbling down is often visible from the start. The fault is that everyone hoped it would go away. It is the responsibility of the Project Manager to identify these problems, and either solve them, or escalate them to the Sponsor.

The Sponsor has a responsibility to the project. Part of that responsibility is, at any point in time, to decide if the project should continue. If there is a major success-threatening issue that the Project Manager cannot resolve, and the Sponsor cannot resolve, the Sponsor has the obligation to stop the project. On the other hand, if the Project Manager cannot solve the problem, and the Sponsor can, the Sponsor has an obligation to fix the problem.

Project initiation is about scouting around to find out if there are any problems that will impede progress and addressing them on day one. The further the project goes, the harder they are to fix. It also means that planning can be more effective because the project manager better understands the context of the project.

Project initiation and interviewing stakeholders is not about gathering requirements. It is about understanding if we have a project, does everyone see it as the same project and can it be a successful project.

Copyright Project Perfect