No one teaches a PM how to plan a project, here’s my ten step process
Many project managers see project planning as a ‘black art’. Funnily enough, planning a projects schedule isn’t really taught per se. New PMs are expected to gather lots of data and simply produce a rabbit out of a hat. I’ve discovered a more rigorous approach which I’ve distilled down to ten steps, and here it is.
All those concerned with delivery and with affecting change MUST fully understand what it is that has to be achieved. The planning process starts by working from top level business aims and objectives down to individual SMART goals. In military parlance this is the Mission. The military theory being that you everyone specifically understands the mission, individuals and teams can act independently (rather than by top down directive) if the need arises, to deliver the desired outcome.
Step 1: Gather and build your team. In the early stages you may well only have a small embryonic team, but you can start to build team spirit and unity of purpose based on the initial planning tasks.
Step 2: Make sure everyone in the team understands the project framework, i.e. the scope, precisely what is to be delivered, and by when. It’s vital that this is written down, distributed and agreed with all the stakeholders.
Step 3: Once everyone is fully aware of the destination you can start working on the roadmap. Build a high level timeline, with the team, which includes the highest level milestones. These are Level 0 milestones, generally driven by the business and are of concern and meaningful to senior management. Remember milestones are used to plot progress and help stakeholders and other areas of the project understand delivery.
Step 4: Develop an understanding of the impacts across the business. For example, if you are delivering change you will invariably impact on the day to day work that people do. Will they need to think and operate in a different way? If so then you have a people and change impact. If you are introducing a new piece of technology or changing an existing implementation then you will defiantly impact the technology domain. Is the change a result of a new regulation or piece of legislation?
Step 5: Use the list of impacted domains to develop your workstream view, which is the first step to deconstructing and simplifying the project. Developing your workstreams should adhere to the following guidance:
- Span of control – no one individual project/programme manager should have so much control over the programme that if they fail the initiative fails. Use the RACI(S) tool to identify if individuals have too much responsibility.
- Leadership – depending on the size of the workstream it should be led by someone who has specific accountability.
- Specialists – Generally speaking the work that goes on within a workstream is specialist in nature. Given that workstream leads should deliver and lead the workstream they should also be subject matter experts in the workstreams that they are leading.
- Concurrency – A workstream should be formed where the work in the workstream can mostly be completed concurrent to other workstreams.
- Dependencies – Notwithstanding concurrency, the chances are that workstreams may be dependent on other workstreams for deliverables. These dependencies should be minimised where possible and all attempts made to eliminate them.
- Maximise resourcing opportunities – multi skilled resources should be used across workstreams. Seek opportunities to share.
Step 6: Even a moderately sized project should be divided up into number of workstreams. When taken together the workstreams constitute the delivery mechanism for all the project deliverables. A workstream is led by a workstream lead who is responsible for managing progress and status reporting of the workstream. A workstream lead could act as a Subject Matter Expert (SME) within the workstream. An SME is responsible for the development of deliverables. Typical workstreams include:
- Technology – designing and building a solution, possibly in collaboration with a 3rd party supplier.
- People & Change – developing the change plan, understanding impact, training and ensuring operational capability.
- Legal & Regulatory – setting policy, understanding the legal and regulatory environment and its impact on the initiative.
- Strategic – developing strategy and ensuring it translates to operations and change.
- Commercial – there may well be an impact on commerciality, this needs to be understood.
- Finance – business cases will need to be developed and monitored. Changes in the finance environment will also need to be led appropriately.
Step 7: Instruct your workstream leads to work with their teams, who will generally be subject matter experts in the subject area of their workstream, to define aims and objectives, timelines, milestones and deliverables.At this stage workstream teams should start to put together their approach to developing the deliverables. Short ‘packages’ of work are required to deliver tangible outputs, whether a design, configuration or process. This approach will then inform the resource plan, i.e. what are the team/SME requirements of particular deliverables? At this point you can devise you Work Breakdown Structure (WBS). Whilst the workstream teams are working on their respective workpackage approach, gather the workstream leads (as a group) to review and amend:
- Confirm the respective workstream aims and objectives.
- Initial workstream timeline schedules.
- Milestones, are they logical and meaningful? Do they reflect back to the overall Level 0 (business level) milestones?
- For each workstream select meaningful Level 1 milestones. These are project milestones used for control and reporting at a project level, not necessarily discussed at the business level.
- Dependencies – workstream leads should now have a view of their respective dependencies. What is it that the individual workpackage, a high level design say, needs from outside the workstream in order to produce its deliverables?
Step 8: It’s at this point that you can produce a ‘dependencies map’. This could consist of a table that details which workstreams depend on which other workstreams (or the business) and for what. Note that the dependency map will inform various schedules.
Step 9: Workstream leads should be prepared to amend their timelines accordingly. For instance if the ‘Org Design’ workstream is dependent on the ‘HR’ workstream for details of future workplace legislation, it stands to reason that the design can’t be agreed until those details are agreed. In which case the HR workstream would either have to front load their work in order to deliver the requirement, or the Org Design workstream would need to pause/re-schedule.
Step 10: Given what the project team now knows it can produce a view of risks and issues
At the end of the planning process you should have a unified team that fully understands what it has to deliver and by when. The team will fully understand the scope of the project, the work breakdown structure and the milestones they need to meet along the way. Everyone, including stakeholders, should also understand the dependencies and the interrelationships between workstreams.