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
Thanks for your posts! It is very well detailed for me who just started with Agile methods! If I may suggest another article that helped me understand this state of mind, for beginners like me http://www.agile-scrum.be/blog/agile-project-management-non-agile-professionals/
Hi Julie. Thanks for your kind words. I’m glad that my article has been useful for you.
Your suggestion is really appreciated; the article by Lorenzo Del Marmol is a well-written one.
What do you think about writing something about your experience using Agile? Though you”re a beginner, every experience has to be considered food-for-thoughts for us.
Let me know.
Finding suitable resources for a large portfolio of projects - via @SaverioLosito #pmot bit.ly/2oZJJQ6
Types of PMO and the journey of maturity - via @SaverioLosito #pmot bit.ly/Jn65Cf
IT Helpdesk Managers: 7 Must-Have Skills, and the 1 Skill You Never Knew About - via @SaverioLosito #pmot bit.ly/1HA8ib1
How to effectively manage the quality of projects without an independent QA department - via... bit.ly/2lAf2zJ
Stay out of the weeds - via @SaverioLosito #pmot bit.ly/Un2tAx
Lessons Learned – The effective Project Management - via @SaverioLosito #pmot bit.ly/157yfee
Con questo codice promo riceverai su mytaxi 20 € per la tua prima corsa che pagherai tramite App: saverio.los - mytaxi.com
The art of Delegation: How to do it Effectively - via @SaverioLosito #pmot bit.ly/2nslyc6
Measuring the Profitability of your Projects - via @SaverioLosito #pmot bit.ly/1TH8gxW
Agile Estimating Tool - Planning Poker using Fibonacci Sequence - via @SaverioLosito #pmot bit.ly/1kRC3Hv
The latest The Program Manager's Paper! paper.li/SaverioLosi… #pmot #projectmanagement
The “recipe” for success in major projects! - via @SaverioLosito #pmot bit.ly/1n9rMqP
Il 49% delle aziende teme problemi di #security e violazione #privacy dai propri dipendenti - fonte @Clusit @polimi pic.twitter.com/n8Al…
How To Give Highly Effective Feedback At Work - via @SaverioLosito #pmot bit.ly/1VWZW0M
4 Mistakes Virtual Managers Make That Stress Out Project Team - via @SaverioLosito #pmot bit.ly/1gHm74r
Top 5 Tips For a Successful Project Manager - via @SaverioLosito #pmot bit.ly/19fdWHQ
The Contribution of a Project Manager to Enterprise Risk Management - via @SaverioLosito #pmot bit.ly/1BseYyr
Future of Work - How It Could Impact You as a Program Manager? - via @SaverioLosito #pmot bit.ly/1D56zGn
Dai un'occhiata a questo Vino. Gli do 3 su 5 stelle con il @vivino app: vivino.com/users/sav…
Profumatissimo, fresco, una bol... Vino da @PellegrinoWine tramite @vivino app: vivino.com/users/sav…
5 Lessons hiding in every Project Management Strategy - via @SaverioLosito #pmot bit.ly/UaEJEI
The PMO - What's the right level of Authority? - via @SaverioLosito #pmot bit.ly/1hboGjf
APMG Change Management approach as a Project Manager - via @SaverioLosito #pmot bit.ly/1MGvMM0
How to create value as a Leader - via @SaverioLosito #pmot bit.ly/2rDwn9J
Using Harvey Balls to Convey Qualitative Information - via @SaverioLosito #pmot bit.ly/2fktjwN
Benefits Management - a Program Management Fundamental - via @SaverioLosito #pmot bit.ly/1yhVfmP
Don't Expect Project Management Teamwork, Lead It! - via @SaverioLosito #pmot bit.ly/1K5yAhT
View my verified achievement from Project Management Institute on Acclaim. youracclaim.com/badg…
Project management survival skills toolkit - via @SaverioLosito #pmot bit.ly/2p5zhnX
6 Project Management Trends To Look Forward In 2017 - via @SaverioLosito #pmot bit.ly/2kUiymR
Help the growth of this blog