We have another set of answers in what would be your PM approach series. This time opinions from Glen Alleman who runs a great blog called Herding Cats. This should be a must-read for everyone dealing with project management, especially for those boxed in one approach. Glen’s thoughts are very insightful and personally I value much our discussions, no matter whether we agree on subject or not. He has also pretty unique background since much of his work is done on huge projects being delivered for institutions like US Department of Defense.
Here are Glen’s answers. There are three situations. For each the question is the same – what would be your project management approach?
You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.
Do we have all the necessary resources for increasing the probability of project success? The Prince-2 process depends on the pre-conditions for success being in place. I’d start with a chartering session where the stakeholders are present. ALL the stakeholders in the same room at the same time. Then, using Prince-2, capture the top level business requirements (business capabilities) in a working session. These top level requirements must not be technical in nature, but must be operational and tied to the success of the business. The units of measure of this success must be meaningful to the stakeholders. They must agree on these units and the beneficial outcomes of the project.
Take these requirements (capabilities) and create a requirements management „tree” in some requirements management tools. These „Tier 1” requirements are owned by the business and the stakeholders, since they are not technical.
Following Prince-2 (which I not experienced at) I’d make sure I had a process advisor on the team that could train, support, guide, and advise all the team members on the various activities inside the method.
But as Project Manager, following the method is necessary but not sufficient. I must have the full attention of the customer at least on a weekly basis to confirm we are making physical progress in accordance with the agreed upon „Tier 1” requirements.
As a process I’d focus on driving every development effort through the requirements traceability to the delivered code elements.
You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.
I’d start with the business side of the house and determine what in their view has been the problem in the past. Research shows that requirements management is a fundamental problem from firms like this to the US Government.
The simplest project management methods are based on making visible what „done” looks like, measuring „done” in units meaningful to the stakeholders, and assuring that these measures occur on fine grained boundaries. The first principle is any successful project – beyond defining „done” – is to answer „how long am I willing to wait before I find out I’m late?” This is the basis of ALL good project management methods. From Ron Jefferies XP to NASA and US DoD 5000.02 Integrated Master Planning.
I have direct experience in this scenario at a large (100) US Department of Energy Nuclear Clean Up site IT project. Define what „done” looks like in a „plan of the week.” Hold each team member ruthlessly to meeting the „plan of the week.” On the Thursday prior, assess progress for the week and reset the „plan of the week,” for the next week.
Weed out the low of non performers on the team. Get the 70 down a leaner 50 or so. Partition the project into separate parallel streams with minimal coupling but maximum cohesion. Do this through a small (1-2) architecture team – handpicked by me, but agreed on by the stream leads.
You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.
As the architect of a fault tolerant process control system I have direct experience in this scenario.
Hire the best damn high availability developer I could find, have a clean and testable architecture, get a toolsmith to support us for everything that gets in our way, build an incrementally developing „simulation” platform to validate and verify the code every day. No one leaves the building until our daily build works against that „test platform.” Repeat daily. XP or Scrum like process work well here as long as the customer is on the team, but doesn’t count as one of our 4.
You can find other people answers grouped in what would be your PM approach series.