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 is, 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
There are three simple truths that also need to be accepted before you can successfully manage your own software projects.
You never have all the requirements going in.
The ones you do have are going to change.
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 on software projects is the customer will ask for a feature, the team will build it, and upon seeing it in action, will the customer has an ‘aha’ moment and discover what they really want or need.
Normally, this would be seen as a good thing! The customer better understands what they want.
Yet by traditional measures this is seen as a bad. A failure in planning. A failure to in the requirements gather process.
This sort of things happens continuously on software projects, and you can’t manage this change the same way you manage capital projects, where change is shunned, and not 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 be 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 sounds 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 know what you really want.
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 have 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 project 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 was 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 re-enforce that 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 try contrast and highlight the difference even further between programmers and construction workers.
As I said, software work isn’t 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.
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 if 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.
It is impossible to gather all the requirements at the beginning of a project.
Whatever requirements you do gather, are guaranteed to change.
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 will 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 than 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 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 to deadlines 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 what anyone does 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 slightly 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.
Filed under: agile Tagged: agile, project management
