on 30 March 2011
This slim volume is a refreshing look at something that I am not used to seeing. I am involved in one project at a time, occasionally more. A project overseer has to have a different view.
If there are several projects, these could potentially have demands on the same (limited) resources. Johanna Rothman has an aversion to context switching, and rightly so, as this produces unproductive time as a change between what was current and what is now current occurs. She makes a forceful argument in favour of allocating resources (machine, people, budget, etc.) to the highest priority item that is to be worked on without distraction, working down a list. It is therefore necessary to rank projects. It is only when ranking has been undertaken that it is known which is the highest priority item. The aim has to be to create release-able running tested features.
Of course, any ranking is not permanent. Rankings change over time, and a high priority item that is not completed may subsequently take a very low priority as the reason for its (early) completion has now disappeared. Rankings have to be reviewed, and Rothman uses the three-fold categorisation of projects, to decide what should be worked on. For each item under consideration, a decision needs to be made; commit, kill or transfer. She strongly advises against any other decision; never say maybe to a portfolio request. When you say maybe, your manager hears `yes'. Your peers and staff hear `no'. You are then placed in a no-win situation.
Part of the commit, kill transform decision can involve recognising projects that can and will not succeed - doomed projects. Killing your own (doomed) project is very different from killing a senior manager's pet project. There are good pointers throughout the book to helpful sections elsewhere, and these are both forward and backward looking, and deal with just this kind of knotty problem.
The resource allocation process that Rothman advises includes never committing more than 50% of your staff for 3 months or more to the same project. Can the project be broken down into something that can produce demonstrable results in under 3 months? If so, it is something that could be contemplated (and may go on to a second, third, fourth stage.) Something larger than 50% of your people and/or longer than 3 months could end up being a `bet the organisation' decision.
In amongst the words are some little gems. She talks of individuals manipulating scoring regimes and metrics - they will do this if there is any advantage in it. Therefore it is very important to watch your metrics, to see if they are telling you the right thing. She advocates Project Managers to start somewhere, but most of all to start. Finally, she advises all against using any form of ultimatum with a senior manager. Her wise words are that these rarely result in anything except a career-limiting conversation for you. That probably means there will be one less person on the payroll - and YOU will be the one leaving.
The view from 30,000 ft is different to that from 500 ft. This book is more about that high level aspect. Knowing about life from that height can actually make more sense of life at 500 ft.
Aiden, a woebegone software developer, sits forlornly at his desk, wondering how to complete three recently assigned, top priority projects. Yesterday morning, the boss told him that the first project was due soon. At noon, the boss popped in to insist that the second one had to be completed immediately. At 5 p.m., the boss announced that Aiden should finish the third piece of work right away. Faced with these mutually exclusive, idiotic demands, Aiden stopped working, updated his résumé, surfed the Internet and played a little solitaire. In the software development world, this sad story is all too typical. The answer, according to software management consultant Johanna Rothman, is project portfolio management. Her book details the numerous benefits of this proven approach to project management. Although Rothman wrote this slightly repetitive guide specifically for the IT world - hence the jargon - anyone who regularly juggles an array of tasks with burning deadlines can pick up some useful fundamentals from her solid report. getAbstract recommends this savvy manual to software development managers, software engineers and related IT professionals, as well as project managers in other fields.
on 7 December 2011
The premise of the book; the fewer number of active projects you have, the less competition the projects have for the same people. That lack allows them to finish projects faster. Sounds great doesn't it? It does! JR explains how to manage your project portfolio. That's not an easy task, but you have to do it. No worries, the book helps you step by step; drafting, prioritizing, and reviewing.
I like the concept in chapter 6: funding projects incrementally. Very interesting point!