Starting a Project – Why Initiate a Project

Starting a Project – Why Initiate a Project (#1 in the series Starting a Project)
By Neville Turbit – Project Perfect

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 cancelling 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 travellers. What usually happens is you end up with some patched up compromise and no happy travellers.

Project Perfect is a project management software and project infrastructure consulting organisation based in Sydney Australia. Their focus is to provide creative yet pragmatic solutions to Project Management issues as well as to set up the infrastructure an organisation requires to successfully manage projects.

Project Perfect sell “Project Administrator” software, which is a tool to assist organisations better manage project risks, issues, budgets, scope, documentation planning and scheduling. They also created a technique for gathering requirements called “Method H”, and sell software to support the technique. For more information on Project tools or Project Management visit www.projectperfect.com.au