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.
September 2nd, 2014
Imagine you’ve hired someone to build your dream home. Before the first piece of lumber is bought, you need to know the floor plans, the budget, and you need to have some idea of the timeline.
This information is part of your project’s scope.
The scope sets boundaries. They aren’t open-ended. You have a defined project with a set budget and timeline. There simply has to be an end to the project or it will never get done.
Whether you’re building a house or creating custom software, the scope of a project is always the same. It includes:
What each of these items encompasses is obviously very different for each project, but every project must have set parameters for each item before work can begin.
The first step is to establish objectives for the project. What is defined at the beginning of the project is what will be completed.
As the client, whether you’re instructing a homebuilder or a software developer, you must realize that everything you say is taken literally. Many times people don’t realize what they say and it gets picked up by five or six programmers in the room. Be very conscious of your instructions. Always double-check your business rules and company operations before you instruct programmers. Your business processes are documented and used as the Bible. It’s what everything is built around.
Along those same lines, we like to warn our clients of potential pitfalls before we begin a project. When you’re building a house, windows will break. Things will go wrong on the client side and on the development side. Communication breakdowns are expected. Instead of hiding from that possibility, we have to think about it, anticipate it and have strategies for working through it.
We found it’s better to be upfront about what can go wrong before it happens. Because if the client isn’t aware ahead of time, they will be very disappointed when something does happen. Having a perfect world mentality in software development is going to lead to a high level of disappointment.
Now that our objective has been determined and instructions have been given to the developers, budgets and timelines are put into place. Everyone involved must know when the project will be completed and how much it’s going to cost.
Finally, phases are determined. You can’t start building your dream bathroom if the slab isn’t laid. We have to break up the project into manageable chucks that can be tested between each phase.