Scope

I'm finishing up the development stage of a project this week. It has been an interesting road with respect to scope. I was brought into the project after the start, actually 8 weeks into the project. When I got here, I looked at how much work was planned and became concerned. Without trying to validate the estimates, I felt there was more work than we could get done by the end of the project.

I worked with the team and client and we were able to reduce the scope by about 20%. Some of this was moving stories into the next release. Some was reducing the complexity of what we were trying to deliver.

As the project progressed, we added more scope. Not a surprise; it should be expected. As the users started seeing parts of the application, they thought of other things to ask for. But here's where we ran into a bit of a jam. We added new stories, but didn't take anything out. We assumed we could absorb the additional work; it only was a couple story points a week.

With about 4 weeks to go, as I looked at our velocity and how many points we had left, I saw we had a problem. When I brought this to the business, they said "we have to have all of this, you need to work harder." Two weeks later, the business saw what I was talking about, it just wasn't all going to get done.

The business identified some stories that could be moved out. The remaining work was still more than our average velocity, so I agreed I would work the team through the weekend to get the rest of the work done.  This was the first time I had asked the team to go above their normal work days, so I wasn't to concerned. If we had been 4 weeks out and expecting 4 weekends of work, I would have been concerned.

We got the work done. Our final tally was slightly higher than what I thought we could deliver right after we re-scoped the work. The real lesson to me is to make sure every time we add even a small amount of work, we make the client aware of how that can impact what we can deliver by the end of the project (their final delivery date couldn't be changed).

A Balancing Act

Good project managers know the importance of managing scope. The customer comes along, asks for a change, you fill out your change request form and get the change scheduled, possibly in a future release or iteration.

But it's not that simple, is it? If you take a hard stand, you run the risk of creating animosity with your customer. But on the flip side, if you give in to much, your project gets out of control and nothing gets delivered.

So how do you decide where to draw the line? You want to make the customer happy by delivering what they want but the key is to deliver.

I've had this situation come up recently with my customer. My compromise was to put a couple of the higher priority requests into the current release, ones that don't have much of an impact on the schedule. The rest I have slotted for the next release. At the same time, I reinforced the idea that it's more important to get the new tool into production, even without every feature, than it is to wait and get it perfect. Once they start using the tool, they will come up with other features, and some of the ones they are thinking about now won't seem so important.

So keep thinking win-win. How you can give the customer what they want while still delivering as soon as possible.

Stuck in an airport

I'm stuck in an airport lounge in Texas, waiting for some weather to clear so I can go home. I had a conversation today with a colleague about what makes projects late (not usually weather).

Our conversation centered around scope creep. Because projects take so long, end users ask for a lot of requirements because they don't think they'll have a chance to get anything else once the project is done. Then they change their mind because it takes so long to deliver what they ask for that the business has changed and now they need something new.

The answer of course is to break the project up; deliver a little at a time. It took me a while the first time I tried to convince a sponsor this was the way to go with a project, but after I successfully delivered a small first release followed by a second release, he became convinced on this approach to running a project. No more huge list of requirements, no more long time periods between gathering requirements and delivering on them, and a happy sponsor. Now if only I could do something about weather delays!