The PROJECT PERFECT White Paper Collection

Starting a Project
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
Your starting point for a project is that you have some vague idea as to why the
project is coming into existence. There is usually some goal that has caused the
project to commence. There are four questions to be answered before you actually do
anything:
• Who are the key stakeholders and what do they see as their role in the project?
• What is their perspective of what the project is all about?
• Are they prepared to commit resources to the project?
• What are the expectations of the outcome?
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.
Perspective of the Project Initiation
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 Project Perfect White Paper Collection

• 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.
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.”

27/06/05 www.projectperfect.com.au Page 2 of 5

 The Project Perfect White Paper Collection

Imagine getting into the project to find a key player didn’t want to play. Not only
that, but we could only get a few hours a week from someone 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.
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 to 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

27/06/05 www.projectperfect.com.au Page 3 of 5

 The Project Perfect White Paper Collection

“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.
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

27/06/05 www.projectperfect.com.au Page 4 of 5

 The Project Perfect White Paper Collection

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.

Neville Turbit has had over 15 years experience as an IT consultant and almost an
equal time working in Business. He is the principal of Project Perfect. Project Perfect
is a project management software consulting and training organisation based in
Sydney Australia. Their focus is to provide creative yet pragmatic solutions to Project
Management issues.
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

27/06/05 www.projectperfect.com.au Page 5 of 5