Starting at Red

Anybody who has worked on projects for any length of time will be familiar with this scenario.

The project starts with lots of enthusiasm, there are no real issues yet and plenty of time available. Status reports are all “Green”. All is well in Project Management Land.

Then issues start to kick in and aren’t getting resolved fast enough. Still the status is “Green” because it wouldn’t look good to raise it “Amber”, and anyway there’s still plenty of time of time to sort everything out and get back on track.

Eventually it’s clear that the project is not going to be able to meet the deadlines and the PM grudgingly pushes the status to “Red” where it remains…

I haven’t analysed it to death, but here’s a suggestion. Start at “Red”. Sounds crazy? Bear with me…

Code Red

When a project starts, the team is as far from delivering anything as it will ever be. Sounds pretty much like a “Red” scenario to me. What if the project remained at “Red” until the PM could justify downgrading it to “Amber” based on progress achieved, and then eventually (hopefully) “Green”?

In theory it shouldn’t matter, but in reality it does. Why?

Why Green doesn’t work

The reason that “Green” is bad is that it means two different things.

At the start of the project we have no idea if we’re going to achieve our goals so saying the project is “Green” really means “we haven’t yet found a reason why we won’t deliver”.

If the project is still “Green” a week before delivery then - you would hope - that it now means “we will definitely deliver”.

If a project starts at “Green” and remains “Green” all the way through, at what point does it go from being “we haven’t yet found a reason why we won’t deliver” to “we will definitely deliver”? At some point it will have changed, but this is not recorded by a change of project status. Strange. Seems like an important distinction to make.

Keeping the PM honest

“Green” is a problem because reality doesn’t work like a textbook. It is usually very hard for the PM to change the project’s status. It can cause panic within a Project Board - and lots of extra work and unwanted attention for the PM. So PMs, particularly inexperienced ones, are very reluctant to change status.

Starting at “Red”, on the other hand, there is no need to worry about scaring the Project Board because a “Red” status is the norm. This clarifies that “Green” only means “we will deliver”, and no project can go to “Green” until it is clear that the progress made justifies the change of status.

The PM will naturally be keen to find reasons to change the status to “Amber” and then “Green”, but this will require delivering good news, and having positive conversations with the Project Board to justify the change - which is much easier than delivering the bad news required to go from “Green” to “Amber” to “Red”.

Empowering the Project Board

When a project is “Green” by default, there is very little for the Project Board to do until the moment when the PM is forced to acknowledge a problem and change the status. Starting at “Red” changes the dynamic. The emphasis of the board can now be on questioning what can be done, and how the board can assist, to go to “Amber” and then “Green” before there is a problem, rather than waiting until it is too late.

The Project Board needs to be vigilant about questioning any change of status by the PM to ensure it doesn’t go “Green” before it is justified. But again, the conversations would be about positive changes, rather than negative ones. A status of “Red” allows the board to focus on the things that are critical to success while there is still time to address the problems.

Creating a questioning environment

When a project is coasting at “Green” it is easy to lose track of what is critical to success and focus on working through a given task list, putting off difficult issues because there is time to resolve them later (we’re “Green” after all).

Starting at “Red” makes it easier to focus the team on the critical activities required to go to “Green”. Everything else is secondary. This is the kind of project environment that is usually only created when there is a serious problem. Why wait until then? Start with the attitude that the project is going to fail unless you take immediate action – because it is!

The challenge

On my next project I’m going to start all my reports with a status of “Red”, and refuse to change status until I have a good reason. When I’m asked why, I’ll carefully explain why it’s better this way. My challenge to all you PMs and BAs out there is this: Do the same. Try it out on your next project, and let me know how it works out.

A bit of history

Since the industrial revolution the trend has been towards specialisation. By dividing up the work into distinct repetitive tasks, and making each worker focus on only one, or a small number, it was found that efficiency could be massively increased.

These gains were obtained in two ways. By specialising, each worker learned to do a few things very well, rather than many things less well. And by ensuring there was no need to continually switch between tasks, it was possible to avoid the inefficiency introduced when people are required to change context.

There is no doubting that these changes made possible huge improvements in productivity, albeit at the expense of worker satisfaction.

Applicability of the model

Unfortunately, an obsession with efficiency and repeatability has ensured that this model is now applied to just about anything, including the kinds of work for which it is inherently unsuited.

Activities that cannot be precisely pre-specified are not amenable to increasing specialisation since they need to apply knowledge to solve problems which cannot easily be done in isolation^[1]. Where communication is required the overhead this introduces quickly swamps any productivity gain from specialisation and becomes a bottleneck.

Projects are an excellent example of an activity that sounds as if it should be possible to achieve great efficiencies by breaking it down into simple repetitive tasks carried out by specialists, but this approach fails - often spectacularly - when this approach is taken too seriously.

Finding the balance

Successful project teams reject attempts to rigidly partition tasks in this manner, and instead take a collaborative approach. Although each person has a specialist area, and takes responsibility for producing specific deliverables, there is an understanding that producing them is not the goal, but a means to an end.

Team members are encouraged to look beyond their specific areas to ensure that what they are working on makes sense in the context of what everyone else is working on.

Great project managers naturally understand, and encourage, this kind of cooperation and look for ways to make it happen - whereas poor ones see only unscheduled or unnecessary activity and take action to try and limit these interactions with predictably dire results.

For practical reasons, scaling to larger projects requires the creation of multiple teams, but it is essential not to create artificial boundaries and to encourage the same kind of collaboration across teams.

Building teams of generalists

Where the limitations of increasing specialisation are recognised, there is a shift in thinking towards building teams of generalists. Rather than recruiting for individuals based on a tick-list of highly specialist skills, the goal is to construct smaller teams (to reduce the communication overhead) of individuals with broader skills and experience who have the flexibility to work across multiple areas.

By all means recruit for specialist skills, but make sure you have generalists working across the interfaces if you want to be successful.

[1] People doing this work are called knowledge workers. Since manufacturing and other repetitive activities are now carried out by machines (or in countries where labour is cheap) most “value add” economic activities in the developed world now fall into this category.

I’ve noticed that people these days are very attached to their ideas, and don’t like having any flaws pointed out, or even questioned.

That’s ok when it’s your own personal interest, but it’s a big problem when you’re part of a team working on a large and expensive project with a lot at stake. A key part of being a good Business Analyst is developing the habit of questioning everything so that you can sort the good from the bad.

Disclosure

In the interest of full disclosure, I’ll admit that before I started working for a living I studied physics to a pretty advanced level. When you study the fundamental sciences you find that it’s really, really hard. And because it’s so hard, you learn to get used to being wrong most of the time.

When being wrong is the default you tend not to become too attached to your ideas or be too fearful of criticism. You also learn how to go about testing ideas, and develop a healthy scepticism of silver bullets.

The reasons your idea is probably bad

The number one reason why your idea is probably bad is that there are simply many, many more ways to be wrong than right. In the space of all possible ideas the chances of hitting on a good one are improbably small.

Of course you can still have good ideas, but it’s likely that you’ll have many bad ideas before you hit on a good one.

The number two reason your idea is probably bad is that there are no really new ideas – only variations on existing ones. The chances are good that somebody else already had your idea, discovered it was bad, and didn't pursue it.

Why that’s ok

A good idea is only recognised as such after it’s been tested - and that means letting others criticise it. A vital part of the scientific process is peer review. This is essentially the process of putting your ideas in front of other people - who are probably smarter than you - and allowing them to shoot.

Einstein wasn’t lauded for his theories of relativity until after they had been pulled apart and survived experimental testing. At the time they weren’t obviously right.

Most entrepreneurs have many bad ideas, and fail many times, before they hit on the formula for a successful company - and become famous for it. You can’t expect to move into a new field and suddenly solve all the existing problems that others have failed to solve. You need to develop a deeper understanding before you’ll be able to spot why ideas are bad and then come up with good ones.

So don’t worry about it

Most of the time you’re wrong, and it’s really ok to be wrong because if you’re not prepared to risk being wrong you’ll never be right.

The path to a genuinely good idea will take you through uncharted territory and take in many false turns. But don’t listen to me, take it from Einstein:

“Anyone who has never made a mistake has never tried anything new.”

― Albert Einstein

These days my colleagues know better than to ask me if I want to go on a “training course”. My answer is usually: “No thanks. Training’s for dogs”. This often raises eyebrows, and I have to quickly explain my rationale.

Importantly, I’m not anti-training because I arrogantly think I have nothing more to learn. On the contrary, I’m the archetype of the perennial student. I’m always voracious in expanding my knowledge and developing a deeper understanding.

But I am skeptical of "training courses" because education – not training – is the key to self-improvement.

These days most people seem to regard education and training as synonymous. However, they are not interchangeable terms. For example, you wouldn’t try to educate a dog (I hope), and top athletes are trained by their coaches, but are not usually educated by them (although this is changing as elite athletes are becoming more aware of the need to understand the latest research in health and nutrition).

Training has its place

The difference between education and training is the level of understanding that is achieved by the student. As the proverb says: “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime”.

My experience is that training courses are much like getting a fish. It may be the tastiest, best cooked, best presented fish, but its use is very limited compared to being taught how to obtain and cook your own fish.

Training does have its place. It makes a lot of sense if you have a need to learn a specific skill, process or technique – such as how to jump a long way (if you’re an athlete), how to perform CPR (if you're going to give first-aid) or how to use a particular software product (if you need to use it for your work).

If I have the need to learn such a specific skill, then a training course makes sense. But I don't get hired by clients because I know a bunch of techniques that can be learned like that. I get hired to solve problems, and the key to solving problems is being able to apply general principles to specific situations.

The power of education

The power of education is that once a truth is understood it can be applied in completely different situations that are independent of the original context. Education enables the “Why?” questions to be answered.

The danger of training, particularly if it is well delivered, is that the unwitting student^[1] comes away with a lot of very good information, but without any real understanding of how and when to apply it - and crucially no idea of practical limitations.

I regularly encounter people who are struggling to apply their knowledge because they treat it as a fixed template to be applied, rather than understanding the underlying principles that make it useful, and adapting them as necessary to the particular circumstances.

Education’s for people

Education takes over from training when we go beyond theoretical examples and rigid templates, and start considering what happens in messy real world situations.

Much like learning to drive, the learning happens after you’ve mastered the basic controls and passed the test. Unfortunately, that usually means long after the training course has finished and the instructor is no longer available to help.

Perhaps modern technology will soon enable us to learn in a more distributed fashion at a pace that better suits people’s ability to absorb and understand. But only if we recognise that there is a fundamental difference between training and education, and deliberately set out to be educated. Leave the training for dogs.

[1] I’ve been that unwitting student.

Nothing is as certain as death and taxes, but on a project you can also guarantee the existence of deadlines. For the purposes of this post, a deadline is defined as a time-based milestone for the completion of a deliverable that absolutely cannot be changed.

Deadlines do not exist as a part of any formal project methodology that I’m aware of, but they are usually imposed anyway. Deadlines are a symptom of a number of common management misconceptions:

• Projects are predictable processes;
• Success can be mandated;
• Team members are motivated by fear;
• Setting hard limits is string leadership.

Projects are not predictable processes

A task like digging coal is predictable. Given a measured average rate for digging coal, it is feasible to predict with high accuracy when a fixed amount of coal will have been dug.

A project, on the other hand, requires the creation of new knowledge and solving unknown problems which are not predictable processes. It makes no sense to assume that a deadline set at the beginning of the project - when the least knowledge is available - will still be appropriate towards the end.

Success cannot be mandated

Advocates of the “command and control” method of management assume that success can be assured by setting a deadline and then making the team work as single-mindedly as possible to meet the date.

This might work well for shovelling coal, since people can increase their average rate of working for short periods, but the creation of new knowledge does not occur faster on demand. In fact it is much more likely that quality will suffer since it is difficult to think creatively under duress.

Team members are not motivated by fear

Nothing de-motivates a project team faster than arbitrary and unrealistic deadlines that cannot be changed by evidence and rational argument.

Deadlines simply create a focus on ways of creating the appearance of meeting the deadline, which takes effort away from actually delivering the project.

Setting hard limits is not good leadership

The key to leadership is setting a good example. Great leaders are open and transparent, and make decisions based on evidence - because they want their teams to work that way too.

There is a better alternative

Setting a deadline is usually intended as a clear statement of intent, and may seem like a good way to motivate a team at the outset. However, once a deadline is set, it is psychologically very difficult to withdraw or change it based on actual progress.

The best way to avoid this problem is to eschew deadlines altogether, and instead set milestones that reflect the key decisions that will need to be made.

Set decision-making milestones…

An example of a common decision-making milestone is the completion of an end-stage report for the governance board.

By phrasing this milestone in terms of a decision "we will decide whether it is the right time to proceed to the next stage", rather than a deadline "we will move to the next stage on X date" the board has the flexibility to adapt to the actual circumstances, rather than feeling tied into a predetermined timeframe.

… and then make decisions

Once you think about it this way, deadlines can always be re-phrased in terms of decision-points instead.  

Rather than a “go-live” date - set months in advance with no knowledge of how much actual progress will be made - have a “go-live decision” milestone when an informed decision will be made on the appropriate date for go-live.

All that remains is to take advantage of these opportunities to make the best possible decisions.

"Know your enemy, know yourself, and you can fight 100 battles without disaster."

-- Sun Tzu

The psychologist Irving Janis did pioneering work on group decision-making^[1,2]. His interest was in how political decisions are made under extreme stress. He identified intense conformity pressures within decision-making groups that seriously restricted the range of options considered, biased the analysis of existing information, and promoted simplistic stereotypes.

Phew. In English, what Janis discovered was that groups of otherwise intelligent individuals can make irrational decisions given the right circumstances - and he identified a number of pre-conditions for this to occur. In essence, groupthink strikes when the imperative of maintaining group unity becomes more important than good decision-making.

Does this sound familiar? A project team under pressure can easily fall prey to groupthink because the typical conditions identified by Janis are often present. In particular, a project team is often: highly cohesive, insulated from outside factors, and motivated by a common goal. Together they face stressful situations and may perceive they are facing external threats to their success.

Under these conditions there is often extreme pressure to conform, and this can result in an environment being created in which anyone questioning a decision, or proposing alternative courses of action, is viewed as threatening the team’s success. By stifling debate, and using authority, rather than quality of argument, as the primary means of decision-making the team’s chances of success are actually reduced rather than enhanced.

Experienced BAs learn to spot the signs of groupthink, and work to combat the corrosive effects. Often this is done by acting as a proxy and airing the views of team members and other stakeholders who may be worried about their career prospects if they voice their true opinions.

To unearth the truth, the BA works with smaller groups or one-on-one, and crucially - without any authority figures present. Once trust has been established the BA can take the flak for airing the problems and forcing a debate without exposing their colleagues.

It takes a thick skin and plenty of self-confidence to carry out this role. Difficult questions are rarely welcomed in these circumstances. Are you ready to step up to the mark the next time you see the signs of groupthink?

[1] Victims of Groupthink (1972)

[2] http://en.wikipedia.org/wiki/Groupthink

George Orwell got it

Whenever I hear the term “Best Practice” I think of 1984. Not the year, the novel.

George Orwell tells of doublespeak, the language of the oppressive state. In doublespeak meanings are reversed: “War is Peace”, “Freedom is Slavery”,” Ignorance is Strength” and so on.

Words are powerful, as Big Brother knew, and repetition can change meaning. So it is with “Best Practice” which now really means “Mediocre Practice”, since it isn’t what “The Best” are doing merely the average or worse the barely-acceptable minimum.

But that isn’t even what I dislike most about the term. Worse is the implication that the pinnacle has been reached. After all what’s better than the best? So by a combination of repetition and implication, mediocrity is now installed as the most desirable state.

IT is still growing up

Information Technology as an industry is in its infancy. It started in earnest fewer than 60 years ago. The reality is we have very little idea how to create and operate efficient, robust and usable software that meets the need of our users.

In another 60 years people will look back at the primitive state of our tools and methods and laugh, just as we now laugh at early attempts at medicine – think leeches! We try to make ourselves look respectable. We copy ideas from mature industries like architecture and engineering. But the reality is that IT projects are still regarded as failures up to 70% of the time^[1].

Calling what we do today “Best Practice” is so wrong it’s not even funny. I know it’s just marketing, but as Orwell knew, words are powerful and what starts as a harmless phrase soon comes to represent truth.

Good Practice

So how do we change this? First we stop using the term “Best Practice”. When you find yourself reaching for this phrase, substitute “Good Practice” instead.

“Good Practice” is always worth striving for, and does not imply that any sort of pinnacle exists. It’s not complacent. It’s open to change and improvement and constructive criticism is welcomed. There is recognition that improvement is always possible. There is always room for something better.

If I’m still working in IT in 60 years, there will still be “Good Practice” - although it won’t look anything like what we do today. Hopefully we’ll also have left the whole idea of “Best Practice” behind us - with the leeches.

[1]  For example:

Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch

The 2015 Standish Group Chaos Report has been released which shows some improvement and lots of opportunity for improvement in the software development industry. Jennifer Lynch discussed the findings.

InfoQShane Hastie

21 Shocking Project Management Statistics That Cost Business Owners Millions Each Year

Check out this blog and learn 21 shocking project management statistics that cost business owners millions each year.

Mavenlink LogoDanielle Richards

“The language of truth is unadorned and always simple.”

-- Marcellinus Ammianus

The primary job of the business analyst is to facilitate communication: Usually between people who share a common natural language, but still find it difficult to achieve a common understanding.

Often this is simply because natural language has a tendency to be ambiguous - with common words having multiple meanings - and this lack of precision leads to differences of interpretation, especially after some time has passed.

For the most part projects also require communication between people who inhabit different worlds (such as business and technical) which have specialised vocabularies, idioms and jargon. To effectively communicate between them requires an understanding of both worlds - to accurately interpret and translate what is being said - and a common language in which to document it.

"You should say what you mean," the March Hare told Alice. "I do," Alice replied, "at least I mean what I say - that's the same thing, you know." "Not the same thing a bit!" said the Hatter, "You might as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see.’”

-- Lewis Carroll

Unfortunately, there is often a tendency to try to solve a complex problem by choosing a tool that has the (unintended) consequence of hindering communication rather than improving it. In business analysis this can be the result of selecting inappropriate languages for documentation.

Over-complicated document templates and impressive sounding, but ultimately meaningless language, are common faults. Complicated^[1] modelling methodologies such as Unified Modelling Language (UML) and Business Process Model and Notation (BPMN) are not effective communication tools for a general audience when used in an unrestricted fashion.

“Everything must be made as simple as possible, but no simpler.”

-- Albert Einstein (attributed)

On the contrary, by continuously seeking to remove ambiguity, jargon and buzzwords from the language used (and clearly defining any required domain-specific terms), an experienced BA aims to document using plain English^[2] and simple diagrams. Standard modelling languages are used but with a carefully restricted subset of symbols which are all clearly explained^[3].

Complicated document templates filled with boilerplate are avoided.

Every sentence or diagram whose meaning is unclear is a potential cost to the project. They can’t all be eliminated, but by keeping things simple there will be more time to tackle the intrinsic complexity of the business problem and less time wasted on misunderstanding and rework.

“Numquam ponenda est pluralitas sine necessitate.”

[“Plurality must never be posited without necessity.”]

-- William of Ockham

[1] The BPMN v2 specification is 508 pages. The UML 2.4.1 specification is 218 pages (infrastructure) and 732 pages(superstructure). That’s complex.

[2] Or other natural language

[3] I try to limit diagrams for no-experts to 4 different boxes joined by two types of arrows