I just finished reading this book and I am glad I read it because it gave me a lot of valuable tips about finishing key projects on time.Just jotting down important points here for future reference......
The fundamental thing to keep in mind is that unless you have information on all the work that you are expected to do you cannot possibly think of finishing the most important things on time. So the first step is to create a project portfolio. Nothing fancy is needed. Just one bucket each for next 4 weeks + one bucket each for next 3 months as columns i.e. total 7 columns. List each of your resources as rows. And in the cell list what project and what feature that resource will be working for that duration. Another key thing to remember is that portfolio monitoring can best be done in an agile environment. Waterfall methodology doesn't provide data needed till the whole work is done....or not done. Following 5 types of work needs to be included - periodic (i.e. done every week or month or quarter), ongoing work, emergency work, management work and project work.
Then at a set frequency (every month or quarter), this folio needs to be reviewed. You have to make one of the following decisions for each project - Commit (this is full commitment, not partial), kill or transform. The projects to be committed to can be ranked based on point system (out of a total, say 10000, points keep assigning points to projects and staff them in the order from highest to lowest), risk or cost (in both these cases a few iterations would be needed to give some idea about the velocity so total cost or risk can be projected) or customers for whom the projects will be delivered (business value). Other ways of arriving at ranking are pairwise comparison, single and double elimination and your product's position in the market place ( features needed to be added to close the chasm between early adopters and early majority rank high).
Important thing to be kept in mind is that you should not do the ranking alone - do it with peers so you will consider all aspects or at least more of them along with doing what's best for your organization. Of course, you need to run it by your superiors for a final confirmation. And don't rank based on ROI, unless you are a custom development group. Also keep in mind that sometimes some internal projects like e.g. fixing the build or auto-testing system can rank higher than external projects because the payoff will be big. If necessary, consider the organization mission, if you have any, do help narrow down the priority of the projects. Chapter 11 on drafting mission - be it your group's or organization's - is a must-read even if the company that you work for has a formal mission.
Review quarterly at least for serial development. For iterative or incremental development, review every time a feature chunk is done or a prototype is completed. You need a demo and data i.e. the team's velocity since last such evaluation to make a decision about the fate of the project. Also you need to take into consideration, project obstacles and organization strategy. So have the right people at the meeting who have this data and authority to make decisions.
So basically it will help to ask following four questions at the evaluation meeting - does the project fit the organization strategy? What's been done since last evaluation (demo will answer this)? How is the team places with respect to the product backlog (velocity and backlog burndown chart answer this)? What obstacles is the team facing (this will give you a measure of risk involved in continuing the project in the same way). If your organization tracks project cost, you’ll need to also know the run rate (the cost of the project per unit time), the total project cost, and possibly the monthly/quarterly/yearly project cost data.
Other trigger points to review your portfolio are - when release dates change, when your customers want something new, when your competitors announce or release new products, or when new technology is possible. Since these events cannot be predicted in advance, a bit of flexibility is needed as far as folio evaluation goes. Allocate time for exploratory work when you do portfolio evaluation.
The ideal time to review the portfolio is:
• When a project finishes something you can see (the project cycles)
• When you have enough information about the next version of a product (the planning cycles)
• When it’s time to allocate budget and people to a new project (the business cycles)
Rothman gives two more golden rules. One that we project managers have known since the dawn of time - that multi-tasking does more harm than good. And two, make decisions as late as possible so you get time to consider many aspects of the situation and changing scenarios to make the best decision. A note about budgeting - Budget target is set for a year but funds are allocated for 3 months. Have a fixed budget for a fixed time and see how many features can be developed.
Keeping a parking lot of projects is also another good idea. The book describes two more concepts - using Kanban and Minimum Marketable Features (MMF). There is some material on fixing the queue length, work size and work cost but I am in favor of fixing the timebox duration. I don't think the other 3 things can be fixed in any meaningful way in an average project.
Project managers often wonder which are the best measures to a project's health. Rothman provides the answer in a no-nonsense way.The only two things that need to be measured are team velocity (current and historical) and product backlog burndown chart. Another thing that can be measured is cumulative flow i.e. work in progress over time compared to the total project scope. The more work in progress, the less this project has provided value to the organization.
There are a couple of points from the book that I find rather far from being practical such as not taking time to put in place an overall architecture but rather letting it evolve as the iterations proceed. You will need a highly sophisticated and experienced team to do that - something which most of us cannot have. Another one, of course, is working with colleagues to make sure everyone is pulling in the direction that's best suited to the organization's goals. This is easier said than done. There is a lot of politics out there and it is not easy to navigate that to make it possible for people to even consider such a notion. Measuring team productivity instead of an individual's sounds about right theoretically but not practically.
That said, I think this is a book worth keeping on your book-shelf if you happen to be responsible for managing a project and a team.
The fundamental thing to keep in mind is that unless you have information on all the work that you are expected to do you cannot possibly think of finishing the most important things on time. So the first step is to create a project portfolio. Nothing fancy is needed. Just one bucket each for next 4 weeks + one bucket each for next 3 months as columns i.e. total 7 columns. List each of your resources as rows. And in the cell list what project and what feature that resource will be working for that duration. Another key thing to remember is that portfolio monitoring can best be done in an agile environment. Waterfall methodology doesn't provide data needed till the whole work is done....or not done. Following 5 types of work needs to be included - periodic (i.e. done every week or month or quarter), ongoing work, emergency work, management work and project work.
Then at a set frequency (every month or quarter), this folio needs to be reviewed. You have to make one of the following decisions for each project - Commit (this is full commitment, not partial), kill or transform. The projects to be committed to can be ranked based on point system (out of a total, say 10000, points keep assigning points to projects and staff them in the order from highest to lowest), risk or cost (in both these cases a few iterations would be needed to give some idea about the velocity so total cost or risk can be projected) or customers for whom the projects will be delivered (business value). Other ways of arriving at ranking are pairwise comparison, single and double elimination and your product's position in the market place ( features needed to be added to close the chasm between early adopters and early majority rank high).
Important thing to be kept in mind is that you should not do the ranking alone - do it with peers so you will consider all aspects or at least more of them along with doing what's best for your organization. Of course, you need to run it by your superiors for a final confirmation. And don't rank based on ROI, unless you are a custom development group. Also keep in mind that sometimes some internal projects like e.g. fixing the build or auto-testing system can rank higher than external projects because the payoff will be big. If necessary, consider the organization mission, if you have any, do help narrow down the priority of the projects. Chapter 11 on drafting mission - be it your group's or organization's - is a must-read even if the company that you work for has a formal mission.
Review quarterly at least for serial development. For iterative or incremental development, review every time a feature chunk is done or a prototype is completed. You need a demo and data i.e. the team's velocity since last such evaluation to make a decision about the fate of the project. Also you need to take into consideration, project obstacles and organization strategy. So have the right people at the meeting who have this data and authority to make decisions.
So basically it will help to ask following four questions at the evaluation meeting - does the project fit the organization strategy? What's been done since last evaluation (demo will answer this)? How is the team places with respect to the product backlog (velocity and backlog burndown chart answer this)? What obstacles is the team facing (this will give you a measure of risk involved in continuing the project in the same way). If your organization tracks project cost, you’ll need to also know the run rate (the cost of the project per unit time), the total project cost, and possibly the monthly/quarterly/yearly project cost data.
Other trigger points to review your portfolio are - when release dates change, when your customers want something new, when your competitors announce or release new products, or when new technology is possible. Since these events cannot be predicted in advance, a bit of flexibility is needed as far as folio evaluation goes. Allocate time for exploratory work when you do portfolio evaluation.
The ideal time to review the portfolio is:
• When a project finishes something you can see (the project cycles)
• When you have enough information about the next version of a product (the planning cycles)
• When it’s time to allocate budget and people to a new project (the business cycles)
Rothman gives two more golden rules. One that we project managers have known since the dawn of time - that multi-tasking does more harm than good. And two, make decisions as late as possible so you get time to consider many aspects of the situation and changing scenarios to make the best decision. A note about budgeting - Budget target is set for a year but funds are allocated for 3 months. Have a fixed budget for a fixed time and see how many features can be developed.
Keeping a parking lot of projects is also another good idea. The book describes two more concepts - using Kanban and Minimum Marketable Features (MMF). There is some material on fixing the queue length, work size and work cost but I am in favor of fixing the timebox duration. I don't think the other 3 things can be fixed in any meaningful way in an average project.
Project managers often wonder which are the best measures to a project's health. Rothman provides the answer in a no-nonsense way.The only two things that need to be measured are team velocity (current and historical) and product backlog burndown chart. Another thing that can be measured is cumulative flow i.e. work in progress over time compared to the total project scope. The more work in progress, the less this project has provided value to the organization.
There are a couple of points from the book that I find rather far from being practical such as not taking time to put in place an overall architecture but rather letting it evolve as the iterations proceed. You will need a highly sophisticated and experienced team to do that - something which most of us cannot have. Another one, of course, is working with colleagues to make sure everyone is pulling in the direction that's best suited to the organization's goals. This is easier said than done. There is a lot of politics out there and it is not easy to navigate that to make it possible for people to even consider such a notion. Measuring team productivity instead of an individual's sounds about right theoretically but not practically.
That said, I think this is a book worth keeping on your book-shelf if you happen to be responsible for managing a project and a team.
Posts
No comments:
Post a Comment