Plan your next move, because every step contributes towards your goal – Sukant Ratnakar
Predictive projects are the ones in which the needs are not likely to change (at least we wish that they don’t change) and where the work being done can be “somewhat” identified and measured. Adaptive projects are those where requirements are likely to change – frequently in some cases – and the work is largely creative with high levels of uncertainty.
How can we correctly categorize our project? Here are some questions to guide us.
If we answered positively to the preceding questions, we’re probably facing with an adaptive environment; we should try to get an Agile approach to manage that kind of project, and the reason is that Agile provides the needed feedback mechanism to deliver adaptive projects.
Okay, we decided to manage our project using an Agile approach. At the first progress review meeting, the management wants to know, “How much will it cost and how long will it take?” Organizational resources need to be allocated to the project. We need to provide feedback at a number of levels to answer the initial set of questions to ensure we are still delivering the best value for our organization’s investment. To effectively answer and satisfy our management, we need to provide them a plan.
In the initial phase of the project, when it’s not a real project but just an initiative to be funded, portfolio and program planning are needed to “do the right work”; in this phase planning is a high-level activity used to decide which initiative deserves to be funded.
When the initial filter has been passed and the initiative has been funded, the detailed activities provided by the analysis of the requirements has to be planned and this is about making sure that the team delivers against the product vision to provide business value on an iterative and incremental basis.
The product vision is a really strategic means that clarify to the team why they are working, what they are working on and what key constraints they must work within. The vision is often detailed in a “Project Charter” document.
As an advice to get an “effective” charter, write it down with the whole team in a collaborative workshop with the project sponsor and product owner present. If the team members who will work on the product are not in the office, let’s get them together for the workshop in order to create a “one team” culture (it’ll be good also as a team building exercise).
If we get someone onboard after the vision has been created, let’s provide him/her a complete “training” using the project charter as a guide to help him/her understand the drivers behind the work being undertaken.
Typical contents of the project charter include:
There are some techniques that can be used to organize the “collaborative workshop” that will produce the product vision. A few are listed below:
The “elevator statement”, also called the “elevator pitch”, is something that will enable any team member to explain the purpose of the project (a statement composed by a few sentences to explain the goals and objectives of the project) in the time it takes to ride between floors in an elevator (imagine you get into the elevator with the CEO of your company and you are asked to explain what the project is you are working on before the elevator gets to their floor).
A simple matrix which articulates the strategic value that the product is intended to provide. The matrix looks like the following table:
There should only be one primary driver and there might be a number of secondary or tertiary goals. Where there is more than one goal in a column then they need to be ranked to avoid the “everything’s critical” conflict.
If we got this matrix filled up as a group activity, we’d help the team to understand the focus for the project.
We could use a simple “in/out list” to define what will be done, not be done and where there is uncertainty about deliverables. When we place an item in the “in” column, we state that the team is responsible for its delivery. When we place an item in the “out” column, we state that the team will not spend any time or effort on it.
When we are uncertain about an item being in scope or not, then we place it in the “undecided” column and the project manager needs to investigate further to identify if the team have to place it in the “in” or “out” column.
At the beginning of our initiative we have to produce a product roadmap, a list of the most important features that the product will deliver to address the scope. Of course if we expect to deliver just one release of the product, the product roadmap will coincide with the release plan.
The product roadmap is a high-level plan maintained by the product owner and the project manager that is expected to change over time and is validated against the product vision (let’s remember to plan also the validation events).
The release plan consists in the list of features that we’re going to deliver in the next release of the product. Of course the features included in the release plan are the ones that the product owner and the project manager agreed to release based on the prioritization made at the level of epics and stories.
A release consists of a number of iterations during which the team will deliver measurable value to the organization.
Stories and epics need to be sized (in story points or ideal days) and prioritized so that the work can be allocated to iterations.
Let’s see how this happens:
Once we have the estimated velocity, it’s time to plan the iterations:
Let’s remember that the release plan is an adaptive plan and will change whenever we need.
Every Agile team should be able to plan the activities included in an iteration based on the lessons from the work done in the previous iterations. They use the iteration planning to validate the release plan and produce the detailed iteration plan.
We should organize one or more sessions of iteration planning to analyze the release plan and update it based on any changes happened since the last update.
Changes could happen, for example, due to:
During the first part of the meeting, the product owner explains the actual priorities and the team revises the iteration plan for identifying the stories to be done in the actual iteration.
The amount of stories included in the actual iteration will be based on “yesterday’s weather”, that is the team’s velocity based on the amount of work done in the previous iteration.
The reason behind the choice of establishing the velocity based on the amount of time needed to complete the previous iteration is that it’s very likely that the team will complete the same amount of work as they did before, unless they have been changed a lot or the working environment has been changed significantly.
The second phase of this meeting will consist in breaking the work down into specific tasks to be “pulled” by every team member during the next iteration, based on his/her ability to do the task in the amount of time initially estimated to complete it. Let’s keep the tasks’ size very small – from a few hours to a day or so.
Now it’s time to allocate the tasks and confirm the commitment of all team members and this is the due of the “iteration manager” (in Scrum he/she is the Scrum Master).
Let’s write the tasks down onto cards (e.g., colored post-it) and hang them up on a large and visible surface (e.g., the wall in the open space where the whole team can see it).
Let’s provide the team with an Iteration Backlog on which all members can find the stories and epics included in the actual iteration.
We could track the progress of all the tasks on a grid placed on the same wall where we placed the task cards. On the grid we could write down the task, who is responsible for completing it, the estimated time to complete it, the remaining hours to complete it and the actual hours used to complete it (so we could measure if we are late or not on our schedule).
The last grid should be completed by every team member to track his/her work against the tasks and represents their daily commitment.
To check our progress, we should use the so-called burn-down chart that is a graph showing the initial estimate and the remaining effort for the iteration.
The burn-down chart can be used by the team to try to improve their estimation skills in the next iteration planning meeting.
Daily meetings are the most important and effective tool used for communicating the progress within the iteration. Every day the whole team gets this meeting and the iteration manager asks the status of all tasks assigned to every team member.
There are a few simple rules to be taken into account and strictly followed by each member.
The iteration manager is responsible for removing all the obstacles declared by the team members (after the standup meeting) so the team can be fully productive.
Just one last rule: we have to keep in mind that we shouldn’t punish our team members for not meeting task commitments because otherwise our task force will adapt to the behavior and won’t tell the truth about the status of the tasks during the standup meeting.
We have to consider that sometimes we will estimate badly or something will happen that prevents someone from working on their task but that isn’t a bad thing, it should be a motivation to improve our skills.
When planning in any methodology you’ll want a tool robust enough to cover all the bases, including monitor that plan and then reporting on it. That’s where ProjectManager.com comes in. Its online and collaborative suite of software provides a project leader with the tools to do the job. Try it yourself with this free 30-day trial.
This article originally appeared on ProjectManager.com
I’m an enthusiastic and highly motivated PMP and Prince2 (Foundation) Senior Program Manager with 16+ years experience in the Healthcare industry. I often work in highly pressurized and challenging environments, managing a large-scale software development program up to an order value of €6M. I’m extremely professional in approach and behaviour, adaptable to change, very meticulous, collaborative, energetic, resilient, innovative, proactive and pragmatic. I’m passionate about process improvement, technology innovation, knowledge sharing techniques and how businesses can capitalize on social media integration. My greatest strength is helping to focus my organization’s efforts on the activities necessary to achieve strategic goals and objectives in order to consistently meet both the customer’s and business’ needs; on time and under budget.
Help the growth of this blog
The latest The Program Manager's Paper! paper.li/SaverioLosi… #pmot
My week on Twitter 🎉: 1 Mention, 158K Mention Reach. See yours with sumall.com/performan… pic.twitter.com/Fukh…
The latest The Program Manager's Paper! paper.li/SaverioLosi… Thanks to @TonyAdams2002 @corneliusficht #pmot #projectmanagement
Siamo alla ricerca di programmatori Full Stack. Dai uno sguardo a questa offerta di lavoro di Healthy Reply.
The latest The Program Manager's Paper! paper.li/SaverioLosi… Thanks to @SusanneMadsen #pmot
My week on Twitter 🎉: 5 New Followers. See yours with sumall.com/performan… pic.twitter.com/mZPE…
The latest The Program Manager's Paper! paper.li/SaverioLosi… #pmot #pmo