A Simple World?
by Paul Hershenson, President
In a simple world, when a client hired a software developer, he would:
In such a world, it would still be difficult to estimate projects, but at least it might be possible within a tolerable range (say +/- 15%).
In the real world, clients (and developers) are human beings.
Consider some examples:
In the real world, every non-trivial requirement, even the ones that appear to be the best documented, are fuzzy to some degree. Clients have new ideas. They change their minds. They have difficulty explaining themselves. That's the reality in which we live (and developers are no less human!) As a project unfolds, managing uncertainty has a far greater impact on the success of the project than the accuracy of the developer's original estimate.
There are four keys to coping with this uncertainty. They aren't rocket science; they're just plain old common sense:
1) Acknowledge and Accept Reality
It's rare to meet a client who doesn't want the best software, delivered as quickly as possible, for the least amount of money. Hey, I'm a client too on occasion, and that's exactly what I want. But as I discuss the realities of software development with potential clients, and specifically the difficulty in coming up with accurate budgets for the project, they often say things like "I know exactly what I want" and "I won't make any changes."
This rarely plays out in reality. Software is a creative process, and creative processes are not linear. When the client sees the software he has envisioned, he will have ideas for improving it, refining it, and clarifying it. Knowing this and accepting it--embracing it even--is the first key to successfully developing great software. It is a very powerful dynamic when the client and developer commit to collaborate in managing a project's uncertainty.
2) Identify Risks and Mitigate Them Early
When Art & Logic was a young company, we did what was for us, at the time, a large project converting a client's DOS application to Microsoft Windows. I was the project manager. The task list was large, with well over a hundred tasks. I carefully monitored the actual hours billed to each task versus the original estimate. With the exception of two tasks late in the project, each task fell within its estimated range. The client and I both felt good about the budget and agreed to a number of non-critical change requests along the way.
Unfortunately, the two exceptions were quite exceptional. They each took ten times longer than expected to complete. The first task was to interface with a third-party data provider. The second task was to use a third-party tool to produce reports. Today, we would have correctly identified those tasks as risk items and scheduled them early in the project. We would have quickly realized that the risk items had been triggered, and we would have taken steps to mitigate them while there was still room to maneuver. Perhaps we would have switched to a different data provider or used a different reporting tool. At worst, we would have known that we didn't have enough budget to add low priority change requests later in the project.
In general, identifying risks and mitigating them early creates the most maneuvering room for navigating around obstacles.
3) Build Headroom into the Project Plan
By now, I'm sure I sound like a broken record. Going into a software project, expect the unexpected. Plan for it. Allocate time for it. Allocate budget for it.
When we estimate a project, we use a software estimation technique called "Pessimistic PERT" (Program Evaluation and Review Technique). One of us will describe it in more detail in a future post. For now, the key point is this: After all the rigor we apply to creating an estimate, we then add a mysterious, subjective percentage to the total to create a range. Over the years, we've described this percentage as the "Gotcha" or "Safety Margin." It's how we build headroom into the project.
We encourage our clients to do the same. If a project has some headroom, and the developer and client have a strong partnership, unexpected bumps along the way can be overcome.
4) Prioritize, Prioritize, Prioritize
And that brings me to my final point: During most projects, especially toward the end, clients will have to make difficult decisions. If time and money are getting tight, they'll need to decide whether to increase the budget and extend the schedule or defer functionality to later phases of the project. These types of decisions are business as usual during software development and should be anticipated.
The developer must carefully consider what's important to the client throughout the project. He needs to focus his attention on the high priority work and leave the lower priority work for later. That way, if the client has to cut scope toward the end of the project, it will be the lower priority, less important functionality, not the "must have" features that are cut.
The world of software development is anything but simple. I'm reminded of the scene in the new Star Trek movie where Scotty describes transporting an object onto a ship moving at warp speed. Successfully completing a software project can be like hitting a target moving at warp speed. But with strong collaboration between client and developer and the application of common sense, it can be done.
In a simple world, when a client hired a software developer, he would:
- know exactly what he wanted the developer to build
- be able to describe it precisely
- never change his mind
- not have new ideas once the project started
- be asking for software that doesn't do anything new or experimental
In such a world, it would still be difficult to estimate projects, but at least it might be possible within a tolerable range (say +/- 15%).
In the real world, clients (and developers) are human beings.
Consider some examples:
The client comes to the developer with an exhaustively detailed spec. The developer builds the software to the spec. The client receives the software, fires it up, and can hardly contain his disappointment. It's what he thought he wanted, but now that he sees it in action, he sees how it should have been done instead. Unfortunately, he's stuck with what he's got because he's out of budget.
The client comes to the developer with a simple concept. Maybe there's a page or two of documentation. Maybe not. The developer estimates the project based on the requirements he knows about. What else can he base his estimate on? As the project proceeds, the client fleshes out the concept, adds detail, and, as a result, adds scope to the project. In the end, he's happy with the software but disappointed that it cost so much more than the developer's original estimate.
The client asks the developer to export data from his application to an XML file. The developer complies. Uh, oh. It turns out the client meant "Excel," not "XML," and didn't realize there was a difference. Now he has to go back to his manager and request a new PO to correct the feature.
In the real world, every non-trivial requirement, even the ones that appear to be the best documented, are fuzzy to some degree. Clients have new ideas. They change their minds. They have difficulty explaining themselves. That's the reality in which we live (and developers are no less human!) As a project unfolds, managing uncertainty has a far greater impact on the success of the project than the accuracy of the developer's original estimate.
There are four keys to coping with this uncertainty. They aren't rocket science; they're just plain old common sense:
1) Acknowledge and Accept Reality
It's rare to meet a client who doesn't want the best software, delivered as quickly as possible, for the least amount of money. Hey, I'm a client too on occasion, and that's exactly what I want. But as I discuss the realities of software development with potential clients, and specifically the difficulty in coming up with accurate budgets for the project, they often say things like "I know exactly what I want" and "I won't make any changes."
This rarely plays out in reality. Software is a creative process, and creative processes are not linear. When the client sees the software he has envisioned, he will have ideas for improving it, refining it, and clarifying it. Knowing this and accepting it--embracing it even--is the first key to successfully developing great software. It is a very powerful dynamic when the client and developer commit to collaborate in managing a project's uncertainty.
2) Identify Risks and Mitigate Them Early
When Art & Logic was a young company, we did what was for us, at the time, a large project converting a client's DOS application to Microsoft Windows. I was the project manager. The task list was large, with well over a hundred tasks. I carefully monitored the actual hours billed to each task versus the original estimate. With the exception of two tasks late in the project, each task fell within its estimated range. The client and I both felt good about the budget and agreed to a number of non-critical change requests along the way.
Unfortunately, the two exceptions were quite exceptional. They each took ten times longer than expected to complete. The first task was to interface with a third-party data provider. The second task was to use a third-party tool to produce reports. Today, we would have correctly identified those tasks as risk items and scheduled them early in the project. We would have quickly realized that the risk items had been triggered, and we would have taken steps to mitigate them while there was still room to maneuver. Perhaps we would have switched to a different data provider or used a different reporting tool. At worst, we would have known that we didn't have enough budget to add low priority change requests later in the project.
In general, identifying risks and mitigating them early creates the most maneuvering room for navigating around obstacles.
3) Build Headroom into the Project Plan
By now, I'm sure I sound like a broken record. Going into a software project, expect the unexpected. Plan for it. Allocate time for it. Allocate budget for it.
When we estimate a project, we use a software estimation technique called "Pessimistic PERT" (Program Evaluation and Review Technique). One of us will describe it in more detail in a future post. For now, the key point is this: After all the rigor we apply to creating an estimate, we then add a mysterious, subjective percentage to the total to create a range. Over the years, we've described this percentage as the "Gotcha" or "Safety Margin." It's how we build headroom into the project.
We encourage our clients to do the same. If a project has some headroom, and the developer and client have a strong partnership, unexpected bumps along the way can be overcome.
4) Prioritize, Prioritize, Prioritize
And that brings me to my final point: During most projects, especially toward the end, clients will have to make difficult decisions. If time and money are getting tight, they'll need to decide whether to increase the budget and extend the schedule or defer functionality to later phases of the project. These types of decisions are business as usual during software development and should be anticipated.
The developer must carefully consider what's important to the client throughout the project. He needs to focus his attention on the high priority work and leave the lower priority work for later. That way, if the client has to cut scope toward the end of the project, it will be the lower priority, less important functionality, not the "must have" features that are cut.
The world of software development is anything but simple. I'm reminded of the scene in the new Star Trek movie where Scotty describes transporting an object onto a ship moving at warp speed. Successfully completing a software project can be like hitting a target moving at warp speed. But with strong collaboration between client and developer and the application of common sense, it can be done.
posted by James at
12:39 PM
<< Home