Summersault Blog

Sometimes I have to remind myself that just because we want to try to be all things to our clients doesn’t mean that we can be. Of course, for any given project, the conversation about what’s possible, and on what timeline, and at what cost is never a simple one. The bigger the project, the more complex that conversation becomes. It can be easy to over-promise and under-deliver if you’re not extremely careful.

Several years ago, we began using parts of the “Extreme Programming (XP)” software engineering paradigm in our development process, with the goal of improving our time estimates, better understanding what we were able to deliver to our clients and when. I’ve not found any part of XP to be more useful than the way it describes the interactions between these four variables:

1. Time: the time it takes to complete a given task or project
2. Quality: the level of quality produced in achieving a given task or building a given feature
3. Scope: the scope of the task at hand - how complex, how many new features at once, etc.
4. Cost: how much we’ll bill for our work to complete the project

The way that we talk about these four variables with our clients is to say, “you get to control three of these, and then we’ll control the remaining one.”

What does that mean? Here are some example scenarios at work:

If a client wants a broadly scoped project done at a high level of quality in a short time-frame, it’s going to cost a lot more than it usually might.

If a client wants a broadly scoped project done in a short time-frame and at a low cost, we’re not going to be able to produce quality because we’ll have to cut corners to make that happen (we never play this scenario out, for what it’s worth).

The ideal for us is working with the client to pick a target cost and timeline, know that we want to produce high quality, and then determine what scope of project is possible given those three variables.

But the bottom line in software development is that, like the laws of physics, you can’t break the rules by declaring that you want tons of new features built quickly at a high level of quality and at a certain price point, and then be surprised when there are lots of bugs, cost overruns, delays in development, or the need to eventually narrow the scope anyway.

I have a sign on the wall in my office, with just the four variables listed out in large font, reminding me of that every day.

A key part of our job at Summersault is to work with clients to understand and manage these variables effectively, to minimize the risks that come with creating complex software (which Extreme Programming is great for), and to make sure the end result is something everyone involved can be proud of.

Tags: business culture, clients, extreme programming, Perl, Project Management, software, software engineering, xp

This entry was posted on Thursday, August 14th, 2008 at 5:38 pm and is filed under Perl, Project Management, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.