An essay for managers and executives who are not in the business of software, but rely on it’s in creation for their business’s success.

Software isn’t like conventional project work. It’s invisible. You can’t see it. You can’t touch it. And you sure as heck can’t measure it (at least by conventional means). Yet it powers just about everything around us and has become indispensable part of business today.

In this essay I am going to attempt to explain why software is different, why you don’t want to manage by conventional means, and some tips on how to survive it’s creation process.

How is software different

Here are some ways in which software is different.

  • The requirements change
  • It’s cost isn’t exponential
  • More people doesn’t help
  • No two projects are the same
  • Construction and design are rolled into one
  • One player can make a huge difference

Then there are the three simple truths that need to be accepted before you can successfully manage your own software project.

  1. You never have all the requirements going in.
  2. The ones you do have are going to change.
  3. You will always have more to do than time and money will allow.

And this is what we do, to deliver value, despite all the change and ambiguity that come with this kind of work.

  • Adaptive planning.
  • Flex on scope.
  • Keep our projects small.
  • Hire the best people.
  • Trust and empower the team and then get out of the way.

Let’s explore each of these in more detail and see what they really mean.

The requirements change

The first inconvenient truth about software development, is that as we build it, the requirements change.

For example, something that happens all the time on software projects is the customer will ask for a feature, the team will build it, and upon seeing it the customer has an ‘aha’ moment and discovers what they really need or want.

Normally, this would be seen as a good thing! The customer better understands what they want.

Yet by traditional measures this is seen as bad. A failure in planning. A failure in the requirements gathering process.

This sort of thing happens all the time on software projects, and you can’t manage this change the same way you manage capital projects, where change is shunned, and not allowed.

The inconvenient truth about software is that

  • Customers often don’t know, or can’t articulate, exactly what they want at the start of a project.
  • Upon seeing what they want, they change their mind.
  • You can’t plan for this discovery and learning upfront (at least not by conventional means).

The cost of change isn’t exponential

If you dust off your old project management books, or look into the latest version of the PMBOK v5, you’ll see a picture that looks something like this:

What this picture is telling us, is that the better we do at gathering the requirements upfront, the less expensive the cost of change will be later. That is sound advice if the cost of change is high.

But with software, the cost of change is low. And we’ve had to get very good at making changes on software projects late in the game. Why?

Because our customers are always changing their minds.
Businesses pivots and changes direction.
And new competitive threats emerge that we didn’t know about at the start of the project.

If you accept this premise, it totally changes how you manage projects.

For one you don’t stress about getting everything right upfront. You stress about getting started.

Secondly, it changes how you do requirements gathering. Instead of investing huge sums of time upfront, you keep your powder dry and save your analysis dollars till later, when you really need them.

We call this just-in-time analysis, akin to just-in-time manufacturing. Just like you don’t want to incur the costs of keeping inventory around your factory floor, you don’t want to incur the cost of carrying around out of date requirements. That’s a big form of waste.

More people doesn’t help

Like the pharaohs of Egypt, I often see traditional project managers attempt to meet unrealistic deadlines by throwing people at software projects. It doesn’t work.

Software isn’t ditch digging. You can’t just parcel it up and throw people at it like conventional work. You may want to do this for optics (to show your bosses you are really trying). That’s fine. Just don’t kid yourself.

More people will slow you down initially. And you should only expect marginal increases later (usually paired with lower quality and higher maintenance costs).

No two projects are the same

Every software project is different. No two have the same:

  • requirements
  • team
  • technology
  • priorities
  • business context
  • operating environment

So you need to treat them as a such. That doesn’t mean you can’t make broad comparisons between groups of projects in terms of size and scope. But don’t be fooled into thinking that because one project went a certain way, the others will to.

Construction and design are rolled into one

Software is one of those neat activities where art, science, construction, and design are all rolled up into one. This has the advantage of requiring less people. But it also means that you have a lot of work going on in one persons head.

I only make this point to reinforce the notion that software development isn’t ditch digging. Not all developers are created equal, and in no other industry that I know of does productivity vary the way it does in software.

Worker productivity varies

I hate using that word ‘worker’, but I use it by design to contrast and highlight the difference even further between programmers and construction workers.

As I said, software isn’t just construction. It’s design and construction rolled into in. You also can’t measure it by traditional means. It’s not lines of code. Some of the best software written uses very few lines of code. It’s one of the few forms of work where you can add value by taking product away.

This means software developer productivity can vary by factors of x2 – x4. In extreme cases x10. Just think about what that means. How do you plan, or set expectations, not knowing the productivity rate of your team? You have to guess.

Three simple rules

There are three simple truths, that need to be accepted, before you begin any interesting software project.

  1. It is impossible to gather all the requirements at the beginning of a project.
  2. Whatever requirements you do gather, are guaranteed to change.
  3. There will always be more to do, than time and money will allow.

These facts, inconvenient as they may be, are what create much of the drama and dysfunction we see in our industry. Traditional project management methods do well with the known. In software we deal with the unknown.

The very act of delivering software changes the requirements. – Kent Beck

Now this is where most projects stumble. They resist change. On software projects you can’t. Change is in your face every day. So we need a way of managing the change which is completely different from what we have done in the past.

Dealing with change

So here are five strategies for dealing with change.

1. Adaptive planning

When reality disagrees with our plan, we change our plan. Not reality. You’d be surprised at how many people fight this.

Instead of ignoring change, we change the scope all the time on our projects. New scope can come in, so long as old scope of equal size goes out. In other words, the way we keep our plans real and our commitments firm is we flex on scope.

2. Flex on scope

To much to do? Not enough time? Flex on scope.

It’s easier than asking for more money.
It’s less risky than perpetually pushing out dates, or cutting quality.
When push comes to shove, we do the same thing you do when faced with a busy weekend with too many things on the to do list. We do less. And cut scope.

3. Keep your teams small

Seymour Cray (the founding father of the supercomputer) once said that the perfect team size for building a computer is one. But he couldn’t do it with one so he bumped it up to twelve.

The same is still true today like it was back in 1976. Smaller teams are better when it comes to software. So keep your teams small.

4. Hire the best people

Developer, tester, and analyst productivity varies. You get what you pay for – this is knowledge work. So if you want a good product, pay your people above average and get good people.

5. Trust and empower

Finally, the people you are hiring are smart, motivated, and want to do good work. Trust them. Empower them. Show them the goal. Ask them what they need. And then get out of the way.

Don’t manage software the same way you would your capital projects

Are you still here? Good. I hope I’ve been able to give you some feel for how software projects are different, why the traditional PMBOK, PMI project management methods don’t work, along with some tips on how to set them up for success.

Software is a risky business. You never know exactly what you are going to get until you reach the end. However, like any creative process, we have ways of delivering great product, while working within our means.

All we ask is you work with us, together as one team, and forgive us when we occasionally do screw up and make a mistake. We want to serve business as best we can. This article is just one attempt at explain how.

Update: Big thank you to Clare Macrae for proof reading and improving the quality of this essay.