When Is A Change A Change?

Change is a natural process. Especially on development projects. Development project Changes arise organically when new information is presented and when new understandings evolve, and new requests are made. Not only is Change a natural part of the development process, Change actually helps make the systems we develop better. Think about one time when during a routine review of a project someone said something that highlighted how a part of the system could be better. That’s the power of Change. The issue is getting developers and Clients to agree that a Change is in fact a Change.

There is a change management process for website and software development projects that’s effective at minimizing subjectivity during the Change management process. This process protects the current project scope by defining only the most recent documented functional requirements as the sole definition of current scope at any time during a project. The process requires new Changes to be added to documented functional requirements, estimated for time and cost, and formally approved. The process was proven successful managing both large and small website and software design and development projects. I call this process the Flawless Development Process™.

Define Change

The Flawless Development Process™ uses ten (10) questions to determine if a discovery, or a Client request, is in fact a “Change” on a development project. The first four questions define what part of a discovery or Client request may be a Change. The last six questions determine if the discovery or request is a Change, or not. This is how it works, if the answer to any of the questions numbered 5-10 is “No” there is no Change. Hera are the questions:

1. What is the “Ask”?
2. Is there a Change in the Ask?
3. What is the Change?
4. What current functionality does the Change affect?
5. Is that current functionality documented?
6. Is the documented current functionality “Approved” by the Client?
7. Have you documented the Change (User Stories and UATs)?
8. Have you Estimated development of the Change?
9. Have you Estimated the Time required to make the Change?
10. Have you presented the documented Change (User Stories and UATs) and the Estimate for Time and development to the Client?

Shared Responsibility

In this process the developer has clear responsibility to:

1. Maintain current documentation of system functionality.
2. Share current system documentation with the Client.
3. Document and estimate Changes when they arise.
4. Present and review documented and estimated Changes with the Client.
5. The Client is responsible for reviewing and either approving or promptly rejecting Changes.

A Clear Process

This Flawless Development Process™ bridges the gap where Clients want what they feel is reasonable, and developers want to get paid for the time they spend developing what they feel is something that is not part of the original scope they agreed to develop. Using the Flawless Development Process™ the Client and developer agree that current documented system functional requirements are the definition of current scope. The way this works is: If it’s not in the documentation it’s not in scope – simple. The Client and developer also agree that any Changes must be documented and estimated by the developer, then reviewed and either approved or rejected by the Client.

Try the Flawless Development Process™ Change on your development projects and say goodbye to unmet expectations and unwelcome cost and schedule changes. Development projects will have other issues to be sure, but there will be real clarity on what is a Change, and what’s not.