Project Management Software
Specialists in Project Infrastructure
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:
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.
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:
I thought at the time
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
the answer will probably be "Yes". If you phrase it
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
I didn't have an answer for him other than to say
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
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:
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.
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.