Why, Blog, Why?

If you're old enough, you might recall the old facsimile that use to adorn at least one wall of every office, back when facsimiles were in fashion, which compared the process of product design to a tire swing. You know the one. (Or perhaps you prefer the "Tire 2.0" version?)

I've recently been working on a project that has managed to creep wildly out of scope. About 300% out of scope, really. And I think the old tire-swing adage just about covers the reasons behind the scope creep:

• The customer already had A
• The customer asked for B, an update & rewrite of A
• I understood it as C
• I built it as D, adding in a few extra features that I thought were "cool"
• When I demo'd the final version to the customer they discovered what they really wanted was E, which was a lot like A

Now that I'm almost finished building E, I have a few thoughts in mind for making sure this doesn't happen with future projects.

1. Save the analysis for later

   I have a bad habit of starting to analyze how to go about transforming something to a digital process while I'm still in the middle of discovery. I've always assumed that this pre-analysis would help me identify gaps or other obstacles while I was still with the client, thus leading me to ask more questions before leaving. In essence, I was trying to complete the discovery phase in a single meeting, something that is completely unrealistic as well as careless. Another problem with this approach is that it means that while I'm busy analyzing in the back of my mind, I'm only partially focusing on the client's description of what they want. If I instead wait to start the analysis until after the initial meeting and accept that it may take several additional meetings before the discovery phase is complete, then I can focus all of my attention on getting the details of what the client is asking for. Any questions that come out later during the analysis phase can be addressed then.

2. Discover the client's assumptions

   It's not enough for me to just listen to what the client is asking for. Often times there will be details that have gone unmentioned. Perhaps the client feels intimidated by what they perceive as my technological superiority. Perhaps they feel that a certain question is "stupid". Perhaps they assume that something is already a given. Or, perhaps they just forget that they have inside knowledge about their organization that I don't. For these reasons, it's important to to try to uncover these assumptions during discovery. The easiest way to get at these is to ask questions about the current process, about the organization, and about the intended solution. Another method would be to ask for a list of measurable goals that will define the success of the project once it is complete. Basically, I need to keep asking questions until I'm out of paper or the client is out of time.

3. Analyze the process, not the request

   Perhaps the foremost change I need to make when scoping out a project is to stop making the mistake of taking the project description from the customer as the be-all, end-all. The customer may be describing what they want, but is it really what they need? By taking the time to understand not just what they are asking for, but rather what they are trying to accomplish I will be better poised to deliver what they truly need.

4. Understand my role(s)

   I may label myself and advertise my services as a web application developer, but most of the time it's assumed that I'm acting as a consultant at the initial meeting. It's only later, once the project is approved, that I start acting as a developer too. In my consultant role, it's my job to make sure the client isn't overlooking some process that is already in place that can be used as-is or with little modification. In some cases it might be my job to inform the client that they don't really need my services because their problem is either already solved by an existing application, or doesn't need to be or won't benefit from being automated. In any case, my only task during discovery should be to understand what the client needs to accomplish and to guide them through the discovery process. That's it. The "developer" can kick in later and pick apart the process during analysis. Until then, I must concentrate on solving the client's problem.

5. Shadow the users

   Chances are that the client hasn't had a chance to work out all of the gaps or consider other alternatives when drafting their request. In order to help them discovery these missing pieces it is essential that I understand how the process currently works. Job shadowing is great for this. Once I identify the key people who are doing the work I can make arrangements to follow them for all or part of a day, watching their daily activities and observing the important parts of the process. It doesn't need to be an interview, in fact I may not need to ask many questions at all. The important thing is that I observe what happens now, so I can translate that into an automated process later. I may even be able to find pieces of the process that can be eliminated or streamlined, perhaps by interfacing with other already automated processes. It may also give me insight into any restrictions that must be worked into the automated work flow. For instance, it may be discovered that a touch-screen interface is required at some access point due to environmental or physical constraints. These on-the-job observations will also help me understand not just what the project must accomplish, but how it will affect the greater organization.

Putting all of these into practice is sure to elongate the discovery phase, but I think that's a good thing. Much of it will still be billable since much of the discovery occurs after the initial proposal. It may be difficult getting clients to see it that way (most of the time they want to know "how much and how long" at the end of the initial meeting), but I think I will be able to justify it knowing now what the alternative may result in.

Do you have trouble with scope creep? Got any other tips for keeping it under control? Please share in the comments section below!