Project Planning
This is a guide I use, there will be changes, when I’m starting a new project and planning to run it. While I’m not a program manager it still is an important skill and workflow to incorporate into your work, no matter the role in IT. Essentially if you’re not working with others to reach your desired end goal, i.e. you’re working by yourself, then it’s probably not that big a project and may not have the people invested to carry through with large systemic changes you want to make.
Note: Always incorporate Design Thinking into the process.
Project Management Phases
1 - Initiate
- Lots of projects are due to systemic flaws and have greater reach than expected. Look into the 5 why’s of the issue the project intends to aid with to see if there are underlying fixes that would eliminate the issue
- Working backwards from the users/customers define a:
- problem statetement
- objective of the project and fix
- scope of the issue, project, and solution
- tenets, if the project is on the larger side
- how does this fit in with the businesses current and future needs?
- Once the above is outlined, have a mission statement and a reason why this thing should exist. This will be your guiding light on how to proceed throughout the implementation
- Use data to sway people about the need of this project. If you don’t have it? Ask and discuss to determine what’s useful here. Some data is better than no data and more data can be gathered over time (this does depend on the specific project of course)
1.5 Discovery phase
2 - Plan
- Get buy-in from your stakeholders, without this you have no place to go.
- With this in mind it’s important to ensure that you frame your plan and it’s reason to exist uniquely for each of the stakeholder type. This is an important step to convince them why they should care, and potentially even help, with your plan and goals.
- Define aggressive timelines, dates, and milestones for completion of the project. These should of course be reasonable and take into account some time for slack but main reason for aggressive is to ensure it’s in people minds and not some adhoc project that can be thought about later (again depends on the specifics of the project)
- Create metrics. This enables you to see the current state and progress of changes you project makes during and after completion. Define:
- what are your leading and lag metrics?
- what are the projects success metrics and values?
- Note: When creating metrics ensure the metric aren’t the cause. Read more into this in Use Of Metrics by Martin Fowler
3 - Execute
- Create a wiki and document your:
- objectives
- mission statement
- tenets
- an FAQ section that can be updated overtime with questions that people ask
- a training section preparing to show people how to use the project, or other required aspects of the project
- Create a tracker of issues and something like a sprint board for showing progress and current assignements. This should be defined by the timeline and required outputs
- Write up a basic plan for running meetings and what should be involved. For more details look into documents created by McKenzie
- Guide to creating leadership and governance of a project
- RACI useful for project management when trying to work out who is involved and how. There are also alternatives which provide other ways to perform this tracking.
4 - Close
- Finalise the project and discuss what worked, what didn’t, etc
- Questions to ask and document on the wiki as part of the wrap up:
- Did the project fix the issue that created the project?
- What do the metrics say versus your expectations of success?
- What learnings came from the project?
- What would you do differently?
4.5 Monitoring & Control phase
- Set metrics thresholds but review in case these change over time, for better or worse. Automated reviews are best, where possible, for comparing values over time. These should also match up to the success metrics of the project as a whole