Reliable Systems

Have you had the experience of looking at a situation and knowing – just knowing, that something was wrong? Perhaps it was a user interface design or a software diagram or project schedule. I’m not talking about a dispassionate concern but an emotional response – you recoiled inside and just knew. Then you had to explain to the person or team that presented the situation why this was the case. Most likely you can draw on your experience and come up with a few very convincing explanations for your gut reaction, but usually you’ll walk away unsettled. It still isn’t right, but you just couldn’t put your finger on it.

Most professionals develop an instinctive ability to size up situations within their core expertise. For example, a seasoned product manager that has worked up through the ranks of developers can often look at a schedule and get a quick feel that it can or can’t be met. Most of the time this intuition expresses itself as a strong gut reaction that you can’t explain. Malcolm Gladwell wrote the excellent book Blink talking about this phenomenon, well worth reading so that you know what to do when you have this reaction the next time.

The basic challenge is this: Even if your instinctive reaction is correct, it isn’t particularly useful until you can explain why. It’s very tempting to try to verbalize the rationalization for your reaction, but don’t. The problem is that your rational mind has no idea why you had an emotional reaction. The emotional reaction is your clue – your intellect and emotions aren’t really connected that well. They need to arrive at their conclusions independently: For you to intellectually justify your reaction you need time to perform a dispassionate intellectual process. Your instinctive emotional reaction didn’t need that time, but it can’t explain itself.

The Path Through The Woods

So if your emotional reaction is equally as reliable as your intellectual evaluation, but you can’t articulate it right away what should you do? The first thing is to develop a code phase for your team that indicates that this is your blink reaction, and not something else. This lets everyone weigh it correctly: It isn’t because you just don’t want to do it or you like another option better, it’s that there’s something instinctively wrong with it. Your team should give it equal weight to you having just expressed a cogent, real argument for there being a problem. Second, the reaction can’t be challenged – at least not directly. It’s an emotional response, so any challenge will drive the participants strait into conflict from collaboration. In our shop, we just say “I have a blink about this…” That cues everyone in.

At the same time, it’s important to recognize that your blink can and will be wrong, sometimes a great deal. It’s no more accurate than a rational analysis of the same circumstance, and that means if the circumstance is something notoriously hard to predict like an election, a project schedule, or a roll of dice then it’s not going to do better than spending some quality time in analysis. This means that when you have a blink reaction then your team should continue with the assumption that the reaction is dead on, but casually seek out the proof.

Casually Find The Evidence

Once you’ve articulated your instinctive blink reaction, have the team take the case that it’s true and then as discussions continue identify facts and data that support the reaction. Eventually, one of a few things will happen:

1. Killer supporting evidence will emerge: In the process of going through subsequent analysis, you’ll find the evidence that suddenly has the reason behind your reaction clear to the team. It’s now an intellectually reasoned response; you just got there faster instinctively.
2. You’ll realize your reaction was wrong: As time passes, your mind will keep attempting to align facts with your reaction seeking to prove or disprove it. Eventually you, or your team, will see what it was that your mind originally caught on and understand that it doesn’t apply in this case: The reaction was wrong, and now you can proceed. This was still an important exercise because you now have validation on your course of action (”we can ignore this previous best practice because it no longer applies because….”)
3. You’ll look at the problem tomorrow and get over it: Perhaps what you felt was just the normal human fear of change. So be it- now that you aren’t feeling threatened any more, your rational mind can reassert itself and look at the item more objectively and be open to new possibilities.

Each of these is a powerful collaboration result because it lets the team and the individual practice and demonstrate the characteristics of a trusting, supporting environment. The team showed the respect for the individual participant and leveraged the experience of everyone, not just those with great oratorical skills. The individual gets to articulate something they feel very deeply without being embarrassed or having to justify and then later defend something that they just can’t. Everyone is in on it – and when the instinct resolves into intellect later everyone will have better insight into the experience and thinking of the person that voiced it. This insight develops trust between the individuals that will live beyond the team.

Finally, by the team not pushing for an immediate defense and then challenging it demonstrates and reinforces that it’s a safe environment to voice ideas and opinions, and builds credibility for when a miss-step happens.

Gaining Speed

Over time as your team works together people may be able to help each other articulate their blink reactions into concrete issues to be resolved based on understanding the key emotional drivers each participant brings to the table. In our company, we have some folks that tend to have reactions over usability, others over ultimate performance (we’ve dubbed one “the keeper of the nanosecond”), and others over code simplicity. Knowing these points helps us not miss-read emotional reactions to ideas and to help each other understand what we really need to do to create the best outcome.

With practice, you’ll find your team can get to great, collaborative conclusions faster and generate the buy-in from the participants with little or no effort.

What Gets You to Blink?

Looking back, when did you have a blink reaction to something? What did you do with it? Share your story by posting a comment or dropping me a line.

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.