Defining the phases
September 16th, 2014
Last time, we defined scope and set our objectives, budget, and schedule. Next, we’ll begin determining phases of the project, which break it up into manageable chucks that can be tested.
Testing takes time and must be budgeted for. If testing isn’t thorough, end users will be frustrated with bugs.
Just like in construction, if a home’s foundation is crooked or cracked, you can’t start framing out the home and building walls. The foundation must be fixed before the next phase of construction can begin.
Continuing with our home-building example, let’s say your home is mostly completed, but your mother-in-law’s health begins to deteriorate and she needs to move in with you. From a building standpoint, if you have the lot space, the change is totally doable. You’ll just add another room and a bathroom.
Obviously the budget will increase and the completion date will be pushed back, but you also have to figure out how to get plumbing to the new section and determine if the extra square footage will affect ventilation. Will you need larger heat and air units? Do you need a second hot water heater to reach that area of the house? Adding to the scope will affect many other aspects of the project that you might not consider.
In the same way, if a client adds tasks to a software development project, the budget will increase and the timeline will be pushed back. New phases and tasks must also be determined.
Now say you were unwilling to move the timeline for your home. The kids start school in August and you need to be moved into the house by a set date so they can start at their new school from day one.
If you maintain the same timeline you’ll be asking the builders to work overtime to finish the job on time. Tired and overworked people will often create an inferior product. They’ll have less time to test the product between phases to ensure all the ducks are in a row.
In much the same way, programmers won’t be able to test your custom software sufficiently. Anytime you overload the programmer with more features, they’ll be less likely to test. You’ll have that feature, but you’ll have more bugs.
Programmers have to sacrifice something to allow time to build that new feature, which means you end up with a less quality project and that leads to user frustration.
Software is never finished. While you should refrain from adding to scope mid-project, it doesn’t mean once the project is over the software is completed. New projects can be created if needs arise at a later time.
You can always build onto your home, just like you can always build onto your software. Software doesn’t start and stop, it continually progresses and grows.
If your software is out of date or isn’t meeting your needs sufficiently, we can help. Contact us today to schedule a consultation.