Reliable Systems

A popular technique in project management is to create and maintain a risks list. This list is supposed to track the things that could cause the project to fail to meet its objectives and ensure that each one gets a mitigation strategy. You generally prioritize the risks by looking at the product of impact and probability: How bad would it be if the risk came to pass, and how likely is that to happen.

Risk mitigation is generally done in three flavors:

1. Make adjustments now to mitigate the risk preemptively.
2. Have a plan ready to go in case the risk materializes.
3. Do nothing and wait and see.

Most project managers (particularly the Project Monitor variety) are highly reluctant to take the last approach: Do nothing, wait and see. They want to have a mitigation strategy for every risk, preferably one that involves taking action now so that the risk is fully mitigated and can be removed from the list. This is counter productive to the project because:

• In the short term it will have the team spend energy and time on mitigating risks of ever decreasing probability, on tasks that are pure overhead in the project.
• In the long term it teaches team members to not mention risks because any risk mentioned will have to be mitigated. This is a strong disincentive to open risk discussion, much like obsessing about defects can cause people to not log defects.

If you want to get value out of a risks list, it has to be treated like a “hold harmless” list: The team has to believe that management won’t hold any risks against them, that they won’t have to mitigate any particular risk on the list, and that intelligent decisions will be made on what risks need to be drilled into. One way to help this is for the project manager to have a strong preference to have each risk either be categorized as Do Nothing or at most mitigate when it happens. Have the team accountable for pushing risks to a higher status by their own consensus. This can remove the fear on the part of team members that identifying a risk and speaking it aloud will cause extra work for the team to debate it and have to mitigate it. Instead, focus your team’s risk list as an opportunity for each participant to identify risks and then suggest mitigation for a risk if they so choose.

Can Your Project Create a Black Hole?

There will be some risks that have a reasonable probability and a serious impact that may require more serious intervention, however there is another item that comes into play at this point. Many high impact risks also should have no reasonable mitigation strategy. If the impact is that the project is sure to fail or even the company is sure to fail, unless you believe you can mitigate it with a modest amount of work, you should probably just let it go. This may seem crazy up front - these are your most serious risks yet I’m suggesting that you treat them as less important than others farther down the list. Quoting World Radio Switzerland (and also from The New York Times):

A lawsuit has been filed against Geneva’s CERN research facility over claims its experiments could destroy the planet. Two scientists in Hawaii say the European Organization for Nuclear Research might create black holes that could swallow the earth. The Large Hadron Collider is the world’s biggest particle accelerator and will essentially crash beams of protons together to create what the universe was like right after the Big Bang. It will do so in a massive underground ring stretching underneath the Swiss and French border and the scientists claim CERN has not fully tested the LHC.

From a project management standpoint, this is essentially the definition of a risk with infinite impact: What could be greater than unstoppable destruction of the Earth? This is a Terminal Risk.The practical reality is that if the result of a risk is that your project will fail, and it can’t be mitigated in a way that still has your project succeed, then you have already failed - if it happens, there’s no solution.

In business, these risks happen all of the time: There is a finite risk that the government will change laws that will ruin the economics of what you do. A competitor could come out with a game changing product that makes you effectively the last buggy whip manufacturer. These are all terminal risks: If they happen, you’re dead. Therefore, spend no time on them at all. Any amount of time you worry about them will not help your project succeed and will only demoralize the team. Additionally, once your team gets focused on a terminal risk, they will start identifying other similar terminal risks, and there’s no running out of them. It is a spiral that doesn’t produce any gain to your project or team.

Instead, focus your energy on the middle set: risks that are reasonable to mitigate, have a fair shot at coming to pass, and would have a real impact to the project. Those are the ones that you’ll have difficulty explaining why you didn’t do anything about them in a post-project review, and your team will likely feel better about the project and the process in response.

That’s right - I set a schedule of publishing an article every Monday and Thursday around 1 AM. If I’m ahead in getting articles ready, I queue them up for the future. But the queue has been empty this week, so this article is late. Now, I’m a creative guy so I have all kinds of reasons excuses for why I didn’t have an article ready either Monday morning or yesterday morning, but that doesn’t change the fact that I didn’t have it ready, so there wasn’t one, so this article is late.

It’s easy to treat being late but with a good reason as being the same as being on time. But they aren’t - and you damage your reputation for reliability if you act like they are.

I used to have an employee that worked for me who couldn’t get to work on time. Now, we had flex time so the definition of “on time” was really broad, but one aspect of it was some rough degree of consistency: If you were going to come in around 9:00, let’s make it average within an hour of that over the course of a month. When he was late, he’d come into my office and I got treated to “Well, I wasn’t late - there was traffic on the Beltway” or “I wasn’t late - I had to take the children to day care because my wife’s car didn’t work this morning” or whatever.

The problem is that why he was late didn’t change that he was late. I’m a really empathetic guy: intent and context matter when you move from what happened to what are we going to do about it. I liked the guy, I wasn’t going to fire him or even do any official HR action because he couldn’t get in on time. I was much more concerned that he didn’t really take ownership of being late than anything else. After all:

• We live in a major metropolitan area. When is the beltway interstate not busy between 8 and 10 AM?
• There are other ways to get your kids to day care. They may not be cheap or reasonable, but they do exist.

The bottom line is that when he looked at what was happening in his life, he chose to be late rather than take another option that would have resulted in getting to work on time. The real problem was that he didn’t see it was really a choice; not that he was powerless in the face of the circumstances of his life but instead that he was choosing to be late. In fact, it may well have been the right choice - I certainly wouldn’t ask him to go to extraordinary or expensive lengths to avoid being late.

Own Your Results

Most software projects I’ve worked on have been late. In fact, I’d say nearly all if you pulled out the letter of the law - did we deliver every feature to every user on or before the delivery date. This is hardly news to anyone that works with software development projects: Most studies treat these projects as “on time” if they deliver 80% of the functionality within 80% of schedule or some other similar tolerance.

As IT professionals, we’ve so internalized that software projects run long, that it’s easy to not see all of the decisions that we made as a development team to be late. It’s a lot easier to assume that we are powerless in the face of the circumstances of our project. But we make choices all of the time that drive being late, and in many cases it may be that the alternative aren’t reasonable (they would be very costly, politically unacceptable, or business unacceptable) but they do exist, you are not powerless to the unpredictability of software. It starts with accepting the development schedule in the first place.

The next time you’re late with something - personally or professionally - find out how powerful it is to just say clearly and emphatically We Were Late, and then move quickly to what are we going to do about it. Arguing about what happened (whether you are or aren’t late) isn’t going to get you to a good answer about what to do about it. In the same message where you deliver that you’re late, make it clear what the impact to others is: What it means to the company, your customers, generally anyone that depends on you.

This may feel like professional suicide, but I’d offer up that the more your organization tends to eat those that admit their mistakes, the more powerful it is to take this approach. As a friend used to remind me, they can’t kill you, they can only fire you. Think about it: If they did, are they the organization you want to work for? Really?

Instead, you’re most likely to find that it defuses the situation: People are ready to confront you with all of the evidence of how late you are and what it means to them. If you’re on the same side of the conversation they are, how much energy can there be in the confrontation?

If you have the reputation as being the first to own up when you can’t do what you said you would, you will have a reputation for reliability even when you aren’t.

As I work with different clients doing software development, I’ve been struck by how different the Project Managers are. From what I have seen, the people in the role of Project Manager tend to fit into one of three archetypes:

• Project Leaders: Command the technical respect of the development team and the business respect of the client. Generally could write the software if necessary, but it isn’t an appropriate use of their time. Nonetheless, they frequently review code and occasionally contribute something because they just can’t help themselves.
• Project Managers: Typically have experience in either the client’s business or general software development, but augment that with specific training in project management tools and principles. Don’t contribute or review code, but actively participate in functionality and technical discussions.
• Project Monitors: Are trained in project management tools and principles, possibly deeply up to and including being a Certified Project Management Professional®. Wouldn’t dream of contributing or reviewing code, can’t actively participate in technical discussions, and can only lightly participate in functional discussions.

Here’s the question: What type of project manager do you need to have the best outcome of a software development project? For the sake of discussion, let’s say the best outcome is the one that produces:

• The most capability, closest to schedule, with the fewest defects discovered in the first 90 days after release.
• The clearest understanding by the participants and internal observers of the status of development during the project.

The first item is the real challenge, because it revolves around the fundamental software development triangle of quality, functionality, and schedule/budget. The problem is that only one of them is really a variable - functionality. Few people will view a project as being successful if quality is significantly adjusted or if the project is late. An experienced team can optimize the effort put into quality assurance, but the largest swings in project effort come from dropping or changing functionality to either save time or eliminate defects. A feature not implemented is a feature that doesn’t have to be tested and proven.

Adjusting functionality to save time seems very simple on the surface - remove new features from the list and the development time that was estimated can be applied to other aspects of the project. The challenge is - how much time will you really get back if you drop a particular feature? Rarely are features so isolated that this is an easy question to confidently answer. Secondly, what is the probability the feature will stay dropped? What may not seem essential to the development team may be the cornerstone reason your sponsor is funding the project.

To make effective decisions about what features can be cut or reduced, you need to be able to:

1. Clearly understand the true incremental benefit in time and quality to the project of the change.
2. Clearly understand the ability of the project’s customer/stakeholders to accept the project as being successful even if that feature isn’t available.

This is parked squarely at the intersection of technical and business expertise. If you don’t know enough about the customer, the feature won’t stay cut - it’ll come back at the request of the people funding the project, and usually do so at a much less convenient time. If you don’t know enough technically, you will tend to over-credit the project schedule for each feature removed. Developers are optimists: They will tend to underestimate how much work it will take to deliver on features in the product, and overestimate the initial savings of removing a feature, particularly if it’s problematic to implement.

Pick Your Battles

Project Leaders - those that have the technical and business skill necessary to intuitively understand what it means to add or remove a feature - are most likely to produce the best outcome on a software development project. They still need to know the techniques and tools of project management - otherwise you won’t have the clarity around the project necessary for people to view it as being successful - but they need to come at it with their business and technical hats in equal measure.

Project leaders are in very short supply, so what projects need true project leaders and which can still be successful with project managers or even monitors? Think of the difference between flying a plane and driving a train. A train is on tracks - you only control one variable (speed). Planes have many more variables - not just traveling in three dimensions but also complexities of many more external interactions. A Project Monitor could drive a train. You need a Project Manager for plane, and your Project Leaders? They’re for the fighter jet on a combat mission.

Monitors can track what’s being done, Managers can contribute to how it’s being done, but a Leader understands deeply why it’s being done and can change up the game when needed to win.

Key Times To Pull Out the Big Guns

Projects that break new ground: When the team will need clear guidance on what’s crucial to deliver and what it means to deliver. A leader can achieve more than the others not just because of the other attributes already described but also because the team will accept tactical management better because of the leader’s technical credentials.

Teams with strong personality conflicts: In this scenario you need both peacemaker and mutual respect, so strong technical and business credentials are important to get each party to stop talking and start listening, then to carry through on the project together.

Projects with no obvious variables: While it’s somewhat of a hyperbole that a project can’t tolerate a change in schedule, quality, or functionality it does sometimes come to pass. In particular, some projects have hard deadlines that are externally imposed and are non-negotiable - like compliance with a government regulation or natural business cycle (the holiday season). These projects need to emphasize creativity in approach to achieve results within tight constraints.

Distributed project participation: When the project is very distributed or requires significant interdisciplinary involvement for success it requires a wider range of business and technical skills to bridge all of the small gaps between mindsets. This often requires a fine listening for what people are repeating back to detect deviations from course while they’re still small enough to fix.

What Are You Looking For?

When looking for new project “leaders”, most corporations emphasize project management skills and techniques - IPMA Level B, PMI Certification, and heavy experience with Microsoft Project or some enterprise project management software package. Not surprisingly, this tends to attract project monitors, not leaders. The next time you’re lucky enough to participate in the selection process of a project manager or leader in your company, think about the hard skills you can’t easily teach them first.