By Dexter Duncan
The Empire State Building was successful in achieving its goal of being the tallest building in the world, building under budget and delivering on-time. From an execution point of view, the architects and builders did well enough for the building to earn titles like “eighth wonder of the world” and “tallest building in world for 40 years”.
Many people do not know that the Empire State Building was a failure at the business level – in fact, it was nicknamed the “Empty State Building” for almost two decades. They often made more from charging tourists to visit the observation deck than they made in rent. One of the golden principles of real-estate is “location, location, location” and the building was erected in an area that left it 50% empty and unprofitable until they sold it in 1951. Nobody wanted to go there, when the Chrysler building, which was completed less than 2 months before, was fully occupied and in a more central location. The reason it was not a success is likely related to how they defined the scope for the project. They achieved quality, built in record time, were under budget and made their goal of being the tallest, but they did not think through the function of the building. Being the largest office building in New York, this is a major oversight.
In Part I of this series, I gave a overview of Project Management based on PMBOK ideas. This post dives into the pre-project, and initiation phase. Pre-project vs Initiation. Prior to initiating a project, the question that needs to be answered is:
Why are we doing this?
The answer to this question is the purpose of the project. The other important questions for pre-project include:
- What organisational goals does this project support/achieve?
- What are project dependencies and and context for the project (especially if there are other projects)?
- What is the business case? – e.g. expected benefits, value, return of investment, alternatives
- What are we going to do? (Scope)
- Who has a vested interest in project being a success? (Stakeholders)
- How will we know the project is successful? (Success Criteria)
The above seven will be carried through and checked, updated and expanded on in subsequent phases. During the pre-project phase, the decision maker (“Executive”) can be appointed from the preliminary list of stakeholders. A Project Manager can also be selected prior to starting the project.
The initiation phase is where the project is set-up and defined.
In this initiation phase, we define who is involved and refine what we will do. Later in the planning stage, we focus on how we will do it.
The key outputs of the initiation stage are to identify stakeholders (including the stakeholder management strategy) and developing a project charter (project definition document). If an executive is not yet appointed, an appropriate person from the list of stakeholders should be made the decision maker. If you are lucky enough to already have team members available, you can start by reviewing all the stakeholders, scope, success factors together with them.
I suggest starting with a list of all the stakeholders or anyone with a vested interest in the project outcome. The stakeholder can be the person paying (i.e. department head, sponsor or customer), senior management, other department/division leaders, suppliers or other outside parties. Give each stakeholder a rating (i.e. high, med, low, etc.) according to their level of interest in the project and share their style/personality/manner and expectations based on your experience.
*Also try to identify if the stakeholder is a negative or positive for the project. Those that want the project to succeed can be enlisted to help and those with a vested interest in the project failing should be treated cordially. This is a balancing act for the project manager. Sharing this with the team is usually best, but sometimes office politics require you to keep the negatives to yourself.
It is important to ensure all the stakeholders are in agreement on the project purpose, goals and success criteria early. It is also important to define a communication strategy to give stakeholders updates on project according to the type of project and personalities involved. Identifying Stakeholders and managing expectations early is a critical success factor. If there is a big risk that quality will not be met, timing will slip or features will be missing, this should be shared early.
Do not over promise and under deliver. Leave yourself some buffers in terms of time and money, as there are often variables outside your control. These unknown variables often start appearing in the planning stage and depend largely on the skill and experience of your team, but also on how well the project scope was documented. The project definition document should be done based on key stakeholder input. The one with the most vested interest is often the one paying (but not always).
Developing project definition document is critical before moving to planning. Some suggestions for the Project Definition document are to dust off, review and expand all the pre-project factors (identified above):
1. Define Purpose by answering “Why?”. What business value is expected, what problems are being solved, what is the objective being supported, etc. A priority level should be assigned to all if there are is list involved.
2. What are you going to accomplish? What are the goals and objectives?
3. Clearly identify all the Success Criteria associated with above goals/objectives. Identify measurable items such as quantity, quality, costs, time limitations or other unique business or support outcomes.
4. Project Context and Dependencies. Identify all the dependencies that could impact results or success of the project. Identify other related projects and how/if they depend on your outcome.
5. Scope and out-of-scope. Clearly identify all the parameters and boundaries for the project. Include definitions, measurements, sketches or anything that helps define what you are doing. The better you define the scope – what is included and what is not, the easier it will be for you to set expectations.
6. Assumptions, constraints and risks. Identify anything that you’ve been given to be true, especially if it comes from outside suppliers or other departments not part of the project. Constraints are usually related to money, timing, resources, skills or technical limitations beyond your control. Anything that is uncertain or could have a negative impact on all or part of the project is a risk. All risks should be identified with their probable causes and probability of happening. A planned response or action in the event of the “risk” occurring is called a risk mitigation strategy.
7. Stakeholders should be identified, along with their role, their decision making authority and information about the department or organisation they are part of.
8. Approach. Discuss the approach to getting the work done and why the recommended approach is better than the other options.
9. Identify all the team members, their roles, skills, availability and weaknesses.
10. Plan the Quality, Identify how measurement and control will be done and decide how project will be approved.
1. Some of the above example planning comes from Managing Successful Projects with Prince 2, Published by TSO, 2005