I've been working on the Statement of Work (SOW) for the new project I am involved with.  The client is looking for a lot of detail.  Initially, I shared my concern about putting too much detail in this document so early in the project.  We discussed the fact that we will learn a lot as the project progresses and the SOW could become severely out of date.

It felt like I would be wasting a lot of time on the details.  I've decided, however, that there are some advantages to this work.  First, there have been some new discoveries.  This project has a fixed budget and fixed time line.  So, identifying more about the project up front is helping us to determine what we can put in the scope and what will have to wait.  Certainly, this will change as we go, but it is nice to have a better understanding of the scope.  Second, as part of Iteration 0, we can use this information to get a rough idea what the overall architecture will be.  Now we know what type of servers we are going to need and a rough idea what services we may need to build.  Who knows, maybe I will discover other advantages later.

Ultimately, I still think we put a bit too much in the SOW, but it may have been worth for the advantages we gained.  The question I am asking myself now is, "Where do you draw the line when composing a SOW while keeping inline with Agile principles."  This is something that will require more thought, research and experience.

posted on Friday, February 15, 2008 5:41 PM
Filed Under [ Agile ]


# re: Agile Statement of Work
posted by Mike Edson
on 11/19/2008 6:04 AM
I'm also trying to develop an SOW for an Agile project.

The question is, how do you define what you are delivering for the fixed budget? How do you satisfy the finance people?

How did your SOW go? Any insight would help.

# re: Agile Statement of Work
posted by Will
on 11/20/2008 3:26 PM

We have been able to manage this project under a fixed budget primarily because we have a separate budget for "funded development". So we came up with our initial proposal and anything outside of that scope fell into the funded development bucket.

This is certainly not the ideal. I would much rather not have a fixed budget contract. The project will likely not be delivered by the original deadline. But, the customer is understanding of the fact that new items have been added to the scope.

So our statement of work had clearly defined "features" and milestones. We are still held to those milestones (meaning we don't get paid until a milestone is complete). But the additional funded development budget ensures that we get paid for the extra work as well.

Post A Comment