100 Rules for NASA project managers

The “100 Rules for NASA Project Managers” has been doing the rounds online for years, so much so that it’s probably reached the status of something of a classic by now. They’ve had their fair share of high-profile failures over the years (solid fuel boosters, Hubble mirror and so on) but these are the relative minority compared to the huge number of successful projects that the space programme has delivered. And while some of the rules fall into the category of the blindingly obvious, it’s a list worth re-reading every now and again.

[Rediscovered via ProjectSteps; the full list can be found here .]

Rule #1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing.

Rule #2: A project manager must know what motivates the project contractors (i.e., their award system, their fiscal system, their policies, and their company culture).

Rule #3: Management principles still are the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it.
Continue reading »

I Can Think Clearly Now

Courtesy of Projects@Work:

You know how you feel when you have a ‘light bulb’ moment, when suddenly the solution to a problem becomes crystal clear. What if those were regular occurrences instead of elusive moments? Here is how to eliminate three bad habits (often mistaken as qualities) that can cloud your thinking and decision-making skills.

Making virtual teams work

If you’re looking to shave a few percentage points off the cost of a project, then opting for a virtual approach can be attractive. Rather than spending oodles of the budget on flights, hotels and expenses, why not cut out all the expensive travel and conduct all the interactions across electronic channels?

The problem with this approach is that it comes with a hidden cost - by eliminating the face-to-face contact, you’re just reduced the chances of building trust between the members of your team. And there’s a substantial body of evidence to suggest that trust between members is a key feature of successful teams.

A recent paper from Dr Niki Panteli from Bath University’s School of Management looked at ways of developing trust within virtual teams, and it’s worth a read if you’re in the throes of building this sort of organisation. The three main characteristics that are identified are shared goals, the dynamics of power within the team, and communication. And it’s this last one for which technology can play a major part.

Part of the communication process that’s highlighted is social interaction, and this is one of the elements that’s removed by a virtual environment - there’s no watercooler around which to congregate. One technique that we’ve used quite successfully is to ensure that there’s at least one physical face-to-face meeting between team members during the course of the project, even if the rest of the work is carried out entirely virtually. By being able to visualise someone as a result of meeting them can help break through the impersonal nature of email, video conferening and phone calls.

A second trick is to put together a ‘biography page’ somewhere on the project intranet. Each team member contributes a mugshot and a potted biography, so that you’ve got a little bit of background context about the people that you’re interacting with. And it also helps to include some social detail as well as the standard work-style resume - try including a paragraph on ‘three things noone knows about me’ in the bio.

And if you’ve provided that sort of background detail in the team bios, you can build on this by the way that the project team communicates. Project documentation can be highly impersonal and dry - while they’re important, status reports and risk logs don’t help to project the individual, and it’s relationships with individuals that will be important when crises strike. Using a project blog as a means of communicating between team members can allow an individual’s personal style to come through - it has a more “3D” effect than formally-dry reports.

How To Learn From Your Mistakes

From Scott Burkun, he of “The Art Of Project Management“:

How To Learn From Your Mistakes

You can only learn from a mistake after you admit you’ve made it. As soon as you start blaming other people (or the universe itself) you distance yourself from any possible lesson. But if you courageously stand up and honestly say “This is my mistake and I am responsible” the possibilities for learning will move towards you.

Non-standard resource availability in Project

A quick way of forcing Project to handle non-standard resource availability:

Task calendars can be used to good effect if, for example, a specialist person or a piece of equipment is only available on certain dates and times. It is also useful when you need to force Project to schedule a task to start on a specific day of the week, say Fridays.

Simple formulas, hidden dangers

Following on from a previous post of mine, Frank Patrick points out another reason why simple formulas have hidden dangers when it comes to calculating potential task durations:

When considering task estimates, we should simply face reality and recognize that estimates are best communicated in terms of ranges and best agreed to as such, and not as single point commitments. The idea of “accurate estimates,” over which too much time, effort, and angst is too often spent in project planning, needs to be set aside.

I’ve often thought that life would be easier (for project managers, at least) if we could get away with using the type of predictions that the Bank of England uses for monetary inflation (PDF link). The graphic is embedded in the PDF, unfortunately, but imagine a line graph where the end fans out into a range of possible values - the expanding ranges shaded by their probability, the darker the more likely (and closer to previous values).

This neatly illustrates both the potential range, and the potential likelihood, of the values. It eliminates the danger of focussing on a single value, but manages to convey the full range of possibilities. It’s an effective graphical way of saying, “there’s a 10% probability of X, but a 50% proability of Y”.

The problem with this approach is that Gantt charts don’t deal with probabilities - they deal with arbitaryly-selected values. And however much you caveat a Gantt chart with ranges and disclaimers, once you’ve produced a hard number, that’s the number that’s going to be quoted.

Estimating Realistic Project Deadlines

There’s an interesting post on Open Loops about the pitfalls of accurately-estimating project durations - and specifically the problem of over-optimistic schedules:

Many project managers can be myopic in this area and not see the potential pot holes in the road ahead of their projects. Being aware of these stumbling blocks and developing a system to accurately project deadlines can bring projects in on time and underbudget.

The technique is an interesting mix of mindmapping and focussing on next actions - in other words, ensuring that you’ve got a realistic and robust work breakdown structure - as well as a formulaic calculation. It’s not clear whether the formula is a rule-of-thumb or has been derived from data, but it’s probably a useful starting point.

I’m always a little wary of formulas - when there’s a calculation to come up with an answer, there’s always a temptation to rely on this as a definitive God-given answer that has to be correct to five decimal places - but if people are involved as a factor, there’s a danger that you’re lucky if the answers are accurate to an order of magnitude.

Nevertheless, it’s a good technique for creating quick-and-dirty “straw men” for planning purposes, and the breakdown steps are a good way of approaching the planning process.

Tickling email in Outlook

A cunning way of managing tickled emails in Outlook…

Scenario planning in project management

Scenario planning is a tool that is used a lot in strategy formulation, but can be very useful as part of a project’s risk management process. By producing a series of future possibilities as a result of a structured and logical process, you can identify risks and test strategies for eliminating or mitigating them.

Some of the advantages of scenario planning include reducing the risk of groupthink or concentration on a single most likely outcome. It also helps with contingency planning, because it forces “what if?” considerations of a situation. There’s also value to be gained from the process itself, because there’s a focus on learning and understanding rather than problem solving.
Continue reading »

A quick technique for stakeholder analysis

It’s not enough to simply know who your stakeholders are. Different players in the project landscape have very different interests in the outcome, and these can change over time. If not all stakeholders are equal, that implies that you need to tailor your approach to them. The question then becomes “how” should an approach be tailored, and “who” should get which approach?

While it might be desirable to deal with every single stakeholder with a personalised approach, in reality that’s unlikely to be possible. So here’s a technique for classifying stakeholders according to their power and influence, and their interest in the outcome.

Continue reading »