I am not a Project Manager

I dislike the title Project Manager.
It conjures up all things evil.
Taskmaster.
Self serving.
On time. On budget.
Doesn’t get software.

Pretty much everything I thought of when I was a full time developer.

And yet today I manage projects.
I create budgets.
I set expectations.
I go to meetings.
I submit status reports.

But I don’t view myself as a project manager.

I don’t own the budget. My customers does.
I am not God (like the PMBOK study guides would tell me). I am a messenger.
I don’t control scope. I inform my customer of their choices.
And I certainly don’t like telling people what to do (though I find myself having to do that from time to time).

Project Management, especially in software, needs a makeover.
It’s too important to be left to the traditional institutions who would have you believe there is one all encompassing framework sufficient for all manners of project.

But more importantly, we as engineers and developers should not be afraid of entering it. Software needs good managers.

So don’t fear the title. Create a new one.

I am not a project manager. I am a developer who managers projects.

Jonathan Rasmusson

Advertisement

Some Inconvenient Truths About Software

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.

Fresh Eyes

Sometimes you get so close to a problem, or you are so intimate with it, that you can’t see how to go about it any other way.

No where is this more true than traditional project planning.

Traditionally, all that mattered to planners to was meet the plan.
On time. On budget.
Plan the work, work the plan.
That’s all that mattered.

There were very strong incentives for managers to do this.
They were paid to meet the plan.
Bonuses hinged on hitting the plan.

And this relentless drive to make the plan, is what has driven, and contributed to much of the drama and dysfunction we associated with traditional project planning. Especially in software.

That’s why change never comes from the status quo.
It takes new eyes and approaches to see problems and solve problems.

It took a group of programmers, to stare down traditional project managers and say enough is enough.

If you have too much to do and not enough time, do less.

This is the basis for Extreme Programming and Agile Planning.
This is why we flex on scope.

Traditional project management is still grappling with this profound, yet simple insight.
They want to be Agile, and be seen as flexible when it comes to adapting the plan.
But they’ve got half a century of baggage and expectation setting slowing them down.

That’s why a revolution in project planning could never come from Project Managers.
They were too busy maintaining the status quo.

It took a group of engineers, with a healthy dose of common sense, to stop the madness, and bring sense back into the process.

The Quantum vs Newtonian Belief System

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager. I think this hits it pretty bang on.

Newtonian – Stability is the norm	Quantum – Chaos is the norm
The world is linear and predictable	Uncertainty reigns
It is controllable	Expect surprises
We can minimize change	We should welcome change
Add rigor to the process to increase the feeling of security	Relax controls to increase the feeling of security
Deliver on the planned result	Deliver to the desired result
Use the plan to drive results	Use results to drive the plan
Aim, air, fire	Fire, then redirect the bullet
Keep tight control on the process	Keep the process loose
Manage to the baseline	Manage to what’s possible
Get it right the first time	Get it right the last time

Estimation War Story – The Double Whammy

Everyone loves a project that comes in ahead of schedule and under budget. But if you consistently too under budget, people will accuse you of sandbagging your estimates and accuse you of being a little too cautious.

This caught me once. We sized a project using the estimates as a range technique, and convinced management to use the upper numbers.

We then estimated our team velocity and again, used a conservative number around how fast we thought we could go.

Turns out we the project was simpler than we thought, and we ended up going faster than we thought we could go, and came in way ahead of where we thought we were going to be. Great news!

Now, I would way rather be on this side of a project (ahead of schedule and under budget) than the other. But when I look back and wondered why our numbers were so big I realized were conservative in our estimates twice:

• Once for the estimates.
• Once for the team velocity.

It’s not the end of the world. This was a really scary project, and our inception deck highlighted a lot of unknowns and first times for the company. There was also some fear and pressure to get things right. But I didn’t quite appreciate at the time that we were sizing conservatively twice here.

I don’t regret sizing it this way. Hindsight is always 20/20.

The more interesting question is now that we are aware of it, what will we do next time.

Happy planning!

The Before and After shot

One way to show change on a project is with the Before and After shot.

You might do this if you inherit a project and you discover it’s bigger than the sponsors originally thought. Or after doing an inception deck and you discover some stuff that was originally missed.

The nice thing about this picture is it’s highly visible or colored. Red can mean new, or bigger than we thought. And the new number at the bottom quickly quantifies the difference and hopefully resets some expectations about what this project is going to take.

Agile Project Status Reports – Example #1

Here are some ideas for project status reports.

The 1 Pager

On this one I am trying to communicate all the important stuff on a single page.

At the top I’ve got how we are doing for time, money and scope. To the right I put any headlines or issues. I’ve got a risk section showing the problems we are facing and how we are addressing. Then the velocity and projected date on the right.

So at a glance I should be able to see whether we are in trouble (via the red, yellow, green stop light) and how we are trending on time, money, and scope.

The Burndown

Ah. My favorite graph – the burndown. The burndown never lies. It’s the story of your project. It shows you how you are trending. It can show where you need to be. It shows you changes in scope. It also tells you when you are in trouble.

Changes in Scope

Every project is different. On some scope management is easy and built around trust. On others you have to watch it like a hawk.

If I think scope management is going to be an issue on a project, I will make any changes to scope crystal clear with a slide like this:

Others

Every company is different. And sometimes I will create dedicated presentations if there is a really important message I need to deliver. But if you basically make everything visible, and ask yourself:

What would I like to see if it was my project?

you’ll probably come close to what your sponsor wants to see to.

War story – Resizing projects

Sometimes you inherit undersized projects. It’s not your fault. You weren’t there for the original estimate. But it’s your baby now and you’ve got to set expectations.

I had to do that recently. I suspected the project was bigger than it looked (thankfully we hadn’t started yet). I did an inception deck with the team and all the sponsors, and lo and behold – it was bigger than anyone expected.

I had to deliver some bad news.

Here is a sanitized form of the letter where I explained to the sponsor why the numbers were what they were, and why the team didn’t feel like it would be safe to go with the lower more aggressive numbers.

Hi Mr. Smith,

After sitting down with the team, and going over the estimates, the team’s best guess is that XXX Project is in the neighborhood of:

325 – 490 days with a strong feeling towards the higher number.

I asked the team if there were areas we could simplify, cut back on, or reduce size in, and was cautioned against the lowering the numbers.

The fact that it is:
– A cross cutting project (lots of stakeholders)
– Distributed team (x3 cities)
– There is no in-house expertise
– Many first times (never done x, y, or z, etc)

tilts the team towards believing this project be slow, with a good chance of surprises along the way.
It’s big. And the team feels there is little risk in finishing early ahead of schedule.

Let me know if you’d like to get together to look at options on how best to present this number and how we should proceed with the budget and schedule.

Jonathan

Actual vs Original Estimate

Unpacking it

There’s a lot going on here (and a lot of missing context and background behind the project). Don’t worry about that for now. Here is what I wanted to share:

1. Estimates as a range.

Even though the original estimates were in days, I like showing stakeholders than when we first give estimates, we don’t really know upfront how long things are going to take (see Cone of Uncertainty).

By showing the estimates as a range, I convey that sense of uncertainty, and it’s a nice lead into Agile planning where I explain how I will soon be able to tell him the exact date.

2. Why the higher number.

This project was about as risky as they get. It was cross company, brand new work with no inhouse expertise, spread across three cities. Nothing in this project was going to go fast, and I needed to alleviate the fear that by some chance the team might finish early and not need the extra funding.

We owe it to our sponsors to be as transparent and visible with regards to where these guesses come from. So I always try to frame it in ways they understand.

3. Actuals vs Estimate.

This project missed a lot of important stuff first time round. That’s why those boxes are red. They represent new stuff (or scope). I like highlighting this and making it really visible, so people can see and feel the size difference. On some ThoughtWorks projects we would use bubbles to actually represent the size to make it feel even more visceral. But you get the point.

That’s it. I just wanted to share this letter/email. I find when writing these it’s best to be clear, simple, and straight to the point.

It’s never fun. But it needs to be done. Bad news early is the Agile way and the sooner you let your sponsor know their project is in trouble the better.

Good luck!

How to manage your project portfolio

Managing a single project is easy.
Managing multiple projects is hard.

Yet this is the state most companies find them in. They’ve had success with agile at the individual project level, and now they are looking guidance on how to manage and track multiple agile projects in one complete portfolio.

Fortunately for us, Johanna Rothman gives us some valuable advice on exactly how to do that in Manage Your Project Portfolio – Increase Your Capacity and Finish More Projects.

Chalked full of great war stories and advice, Manage Your Project Portfolio shows you how to:

• Create a portfolio for your projects.
• How to rank, prioritize, and evaluate which ones you should be doing.
• How to socialize and collaborate on what you are delivering.
• As well has how to iterate and make decisions at the portfolio level (instead of always down at the project level).

I really like some of the sidebars and stories Johanna has collected. Johanna reminds us that:

Two part time people do not make one full-time equivalent.
Sometimes killing a project is the best thing you can do.
And my personal favorite – fund projects incrementally instead of all at once.

If you are looking for advice around what to measure when tracking your projects, how to come up with an actionable mission statement, or just how to effectively communicate the state of your portfolio ask Santa for a copy of Manage Your Project Portfolio. It could be exactly what your company is looking for going into the New Year.

The NOT list

Imagine two of your best friends are about to go on a blind date but each was wildly different expectations around how the date is going to go.

Unless you or someone steps in a resets some expectations someone is going to disappointed.

What if instead of proceeding as if everyone was on the same page, you step in and lay down some grounds rules BEFORE the big night. Specifically, you make it clear certain things are off the table.

Now before the date even starts both parties can decide is this date is even worth pursuing.

That’s the idea behind the NOT list. A clear, simple, unambiguous way to set expectations around what you are not going to be doing on your software project.

The NOT list

The NOT list is about making it super clear what’s in (and even more importantly out) of the scope of your project.

IN the big rocks we need to move on this project.

OUT stuff we are going to ignore. It’s off the table.

UNRESOLVED things we still need to figure out. Ideally would move these to IN or OUT before the project begins.

This doesn’t mean the scope isn’t going to change, or we aren’t going to discover things along the way. It’s simply a stake in the ground that says: “No matter how bad things get, if we do these xyz we are going to be OK.”

With a solid NOT list in hand, story writing now becomes a breeze.
You and your team can focus only on the really big rocks and forget everything else.

To learn more about the NOT list, and nine other questions you’d be crazy not to ask at the start of your project, check out the Agile Inception Deck section of The Agile Samurai.