Summary.
1. Understand and familiarise yourself with the IT system landscape.
2. Identify the stakeholders and understand their interest and role in the project.
3. Define and document the scope.
4. Breakdown the scope into high level work packages and estimate the effort and cost.
5. Create a high-level project plan.
I know that starting a new project can be overwhelming. It may feel like there is an endless amount to do and it’s hard to decide what to attack first. I can help. In this blog I’m going to share the exact first five things you should do when starting a new IT project that will give you a strong foundation for success. This is the method I have developed for myself over twelve years in change management. If you don’t start with these five things, you are at greater risk of setting your project up for failure.
Number one: Understand and familiarise yourself with the IT system landscape.
Before you can take any meaningful action to deliver the project, you need to understand the ‘lay of the land’. If you don’t, then it makes it hard to understand what the project is trying to deliver. An IT project will likely be centred around one technical element, for example, a system, a piece of software or hardware, or a database. Consequently, the first thing you should do is get to grips with the key technical element. E.g., how many servers does it use? What is its operating system? What database does it sit on? What is the purpose of the system? How does it operate? You don’t need to go into too much technical detail, just the high-level information is fine. Understanding and learning this upfront will make every project conversation and meeting easier to have.
You may have a project architect on your team who can do all the research for you. If not, then you will need to ask around to get the information yourself. There may be IT contacts, business contacts, architects or subject matter experts (SMES) that can help you. Do some digging, like an old-fashioned investigatory journalist. It’s easy. You start with one lead (e.g., a contact name) and you follow up on it. Then you get more leads, and you follow up on them. You start to build yourself a picture of the current IT system landscape, what’s commonly referred to as the ‘as is.’ You must understand the ‘as is’ before you can plan the ‘to be’.
Once you understand the key technical element you can start mapping the wider landscape. Draw a diagram. What are the upstream and downstream systems? Are there any systems that sit on top of the key system, like a reporting layer? How is information passed between upstream and downstream systems?
The IT landscape is the foundation to everything. Understanding it does the following.
• Puts the project objectives into context.
• Acts as a project visual aid.
• Helps to set the boundaries of the project scope.
• Helps to identify any potential project impacts.
• Helps to identify and map out the project stakeholders.
Once you understand the IT landscape, it’s time for step two.
Number two: Identify the project stakeholders and understand their perspectives.
Now that you have the IT landscape documented, it will be much easier for you to identify the project stakeholders. A stakeholder is anyone who has an interest in the project. Some stakeholders will do actual work on the project, some will make decisions, some will be impacted by what the project is delivering, and some will do all the above. It is crucial that you identify and engage with all the stakeholders to understand their perspective. This is especially important at the start of the project when you are defining the work and preparing a plan. Failing to identify and engage with stakeholders at the start of a project could lead to the following.
• You fail to identify project impacts that could stop your entire project.
• You fail to secure key project resource due to providing insufficient notice.
• You fail to identify all the project scope, leading to scope creep, delays and unexpected costs.
• You fail to identify all the approval forums required to sanction your project.
• You isolate, annoy and even upset influential stakeholders.
The exercise of identifying all the stakeholders is best done with a group of people. Work with some folk who know the landscape and business well. You can use the IT system landscape diagram as a starting point. For each system, identify the following.
• Who ‘owns’ the system?
• Who ‘owns’ the data in the system?
• Who uses the system?
• Who operates the system?
• Who fixes the system if it breaks?
• Who audits the system?
• Who can change the system?
A great way to capture all the stakeholders is by creating a stakeholder map. See my article ‘how to create a stakeholder map’ for more details.
Once you have identified your stakeholders, it’s time for step three.
Number three: Define the project scope.
The project scope is a high-level summary of everything the project is going to deliver. Everything. The project shouldn’t deliver anything that does not fit into the high-level scope. Therefore, as a project manager, it is crucial that you have a total grasp on the scope. It must be crystal clear to you. Not only to know the scope but also to understand the scope. If part of your scope is to, for example, ‘transform the data,’ do you really understand what this means? Believe me, if you are not clear on the scope, then your team will not be clear on the scope. If your team is not clear on the scope, then your project will have many problems.
With IT projects, scope at its highest level is usually straight forward. For example, ‘upgrade a system,’ ‘migrate some data,’ or ‘build some infrastructure.’ However, this overall objective will break down into smaller chunks. There will also likely be some enabling activity to do to allow you to deliver the overall objective, as well as activity to mitigate any unwanted impacts that result from it.
You should not try to define the scope by yourself, you should do it in a workshop. This reduces the risk of missing something, and it gives people a chance to input and feel part of the project. Use your stakeholder map to decide who is best able to help you define the scope.
Remember, the scope should be high level. There may be much more detail behind each scope item, but this will be defined later in the requirements, which breaks down the scope in line-by-line detail. Generally, if you find you have more than 10 scope items you will want to challenge if you are going into too much detail.
Once you have captured the scope, spend some time agreeing who should sign off or approve it. By seeking approval from all key stakeholders, you will identify any impacts the project may have on other systems or people. You may find some of these impacts lead to increased scope, or you may find they are unacceptable. Once all the impacts are known, you can refine and finalise your scope. You should not proceed with any development work before the scope is fully agreed, although this is not always possible.
Once you have your scope finalised and approved, it’s time for step four.
Number four: Break down the scope and estimate the work effort and cost.
Now that you have the project scope, you can start to break it down a bit. I say ‘a bit’ because you don’t want to go into too much detail, just enough so that you can estimate how much work and resource is required to deliver it.
Again, you will need to do this with a team. Refer to your stakeholder map for the right people to invite to a workshop.
A great tool for this exercise is called the Work Breakdown Structure (WBS). Take each scope item individually and then think about all the key components that must be completed to them. Think of the components as the largest building blocks of the scope item. As a guide, you should break down each scope item into three to eight components. These should be just low level enough to be able to estimate what resources (i.e., specialists) are needed to do the work, and how much time they to do it.
At the end of the workshop, you should have a WBS that breaks down all the scope items into key components and the resource requirements to deliver them. If you add all this up, you will have a rough idea of how many man hours will be needed to deliver the work, along with the monetary cost to do so.
At the end of the workshop, spend some time thinking about other costs that are not directly attached to ‘doing the work’. For example, hardware costs, licence costs, etc.
Once you have broken down the project work into quantifiable chunks, you are ready for the next step.
Number five: Create a high-level project plan.
The project plan will be your most important tool. It should be referred to, updated and refined constantly. Without a good plan, it is very difficult to be a great project manager.
The project plan is your documented approach for delivering the scope. The scope is the ‘what’, and the plan is the ‘how’. There should not be anything on the project plan that is not delivering, or enabling the delivery, of the project scope. Likewise, there should not be anything in the scope that is not captured on the project plan. The scope and plan go hand in hand.
At this early project stage, you are only going to create a high-level project plan. Ideally, it should fit on one page and be easy to read. This plan will capture all key activity and milestones that need to be delivered to achieve the project objective. This exercise will reveal when the project can realistically complete or ‘go live’.
As with the other steps, you should create your high-level project plan with a team. Refer to your stakeholder map and invite the most appropriate people to a planning workshop.
Use your WBS as the starting point. You already have all the project components documented. Now you need to understand the order these components should be delivered in. Once you have established this, you can add the start and end dates of each component to a timeline. This is the foundation of your plan.
Remember, this is a high-level project plan and will need some refinement. To create a high-level plan, you will need to make some assumptions. Document these assumptions, along with any identified risks. This information will be required to enable stakeholders to approve the plan.
Once the high-level plan is drafted, you will need to share it with key stakeholders for review and approval. It is critical that anyone who has a task on the plan review and approve it.
With the high-level plan approved, you will be set. With a robust project plan, you have set the foundation for a successful project. Not only do you have an achievable plan that can be managed, but also a team that has signed up to it. Keep in mind, you can only create a robust project plan if you have completed the first four steps thoroughly.
That brings us to the end of blog! Thanks for staying with me and I look forward to sharing more project manager tips with you next time.
Project Manaverse 