A project manager has to fly an interesting route, where we have to stay at 10,000ft to maintain the vision, and monitor the big picture – when and where are the milestones, are any risks become more likely to occur, what report is next due – but at any point we can be called down right into the weeds and sweat the details.
Starting with the vision, I like how Jim Highsmith suggests we handle this by distilling the Vision down to an ‘elevator pitch’ (a brief statement that can deliver the project vision in a few seconds):
For (target customer) who (statement of need or opportunity), the (product name) is a (product category) that (key benefit, compelling reason to buy).
Unlike (primary competitive alternative) our product (statement of primary differentiation).
For a Senior Risk manager who needs to see their full Portfolio Risk exposure broken down by category, asset, trading desk, issuer, or custom tag, the ÜberRiskMasterBlaster 5000 stores multidimensional data in a bespoke OLAP Cube which in turn is analysed with a series of optimized MultiDimensional eXpressions (MDX) queries that will deliver a series of custom risk views and reports that can be sliced and diced as the user needs or desires and can also be exported to downstream Business Intelligence tools.
Unlike Nasty Corp’s RiskMangle Pro Deceive-Inveigle-Obfuscate module our product is optimised for real-time user analysis and dynamic custom views.
The idea here is that all the team should now possess this vision, that any one of them stuck in the elevator with a CEO asking ‘so, what are you working on?’ (ie. it’s 2 weeks before I decide the bonuses and lay-offs, justify your existence) could quickly, and succinctly, deliver this 30 second pitch on the ride between floors.
So with this in mind, we need to get a correct balance between getting the details and big-picture, between the tactical and strategic views. Of course, a lot of this will come down to the culture of the organization – are ‘managers’ expected to monitor and assign daily tasks -, the nature of the project style – Waterfall will need to be tracked at the task level, whereas Agile will be at a feature level and the team pretty much left to it during the iteration – and how well things are going – if the wheels start to fall off, or a potential risk is starting to move from potential to real, you’ll be down in the guts pretty damn quick – as well as personal style – a more hands-on PM living and breathing a single project is going to closer to their team than one running a team of PMs, or running a portfolio/program become extant.
As a general rule, I’ve found that although there is a requirement to get right down into the weeds at the start of the project, during the negotiations, the scoping, and the planning. Once the work starts, you need to get up to altitude to get the larger and more strategic route established. The work can be assigned in larger chunks, large enough that the team will be able to work through it without you micromanaging them. There will still be times you’ll need to get down into the details on a regular basis. For Waterfall, this could be for tracking completed tasks. For Scrum, you might be grooming the backlog or conforming iteration backlog items completed to track velocity.
For Waterfall projects, one method I’ve seen work is to simply decide whether a task is pending, started, or finished and to use 0% completed, 25% completed, or 100% respectively. There is little gain in trying to sweat whether task X is 35% or 45% completed.
For Scrum, the development team has taken a greater level of ownership and responsibility and so the tracking really only takes place at the end of the iteration when the Product Owner decides whether a feature that was agreed to be in the iteration is done or not. The only exceptions will be the backlog grooming meeting, where we dig into the features for the next iteration, or if the team request you need to dig into a problem they have or need you to chase the Product Owner to clarify a feature, assuming you’re in the Scrum Master role.
However, sometimes you can find yourself bogged down in the weeds. For example, if the client is concerned that the number of risks, issues, or actions are starting to grow, it is no-ones interest to stay stuck at ground level. This is more of a risk for Waterfall projects.
One method I’ve seen work here is to short-circuit the (usually endless) debate and agree with the client’s senior management team and key stakeholders that you will create a status document to detail a) the current status of the project, b) the known issues, how they will be addressed, and in what timeframes, and c) how we’re mitigating the risks. This gives them confidence that we’re in control, that there are clear milestones on how we’ll get things back on track, and d) they can read about it rather than sucking up more meeting time. A lot of this information should already be at hand in a Waterfall project so it isn’t too great a burden and a small price for getting back up to altitude to monitor the big picture.
Although you can live a project skimming at tree-top level, this is both exhausting and dangerous. Exhausting, as it requires complete focus and relentless attention. If you get distracted for a moment, it is going to get very ugly, very quickly. Dangerous, as you are totally reliant on the ‘map’ you drew at the start of the project. If the map is wrong, or the landscape changes, or something starts to go wrong then you will have less time and space to react, and virtually no opportunity to be proactive.