Abbreviated Scope Vs. Full Scope… Which is right for your organization?
(Skip to the Long Story Short, Click Here)
When a boxed application simply isn’t fulfilling your organization’s needs, you may decide to have custom software developed. The great part about custom software is that it can be completely tailored to your organizations processes and procedures, creating efficiencies that can have serious bottom line benefits!
When starting a custom software project, be it a website, small web app or an entire enterprise application, the big question is: “Where do I start?”. Like almost any project, it’s a good idea to start with some type of blue print; deciding which type is right for your particular application and your business’ budget is something only you and your team can decide.
The most common two paths for starting a custom application are an abbreviated scope and a full scope.
An abbreviated scope usually involves fact finding meetings to further understand the application’s purpose. From this meeting comes the abbreviated scope – a “bullet point” version of a full scope. From here, developers start hammering away at the code, providing progress updates throughout. The ongoing steps are usually much more casual and fluid than a full scope, since there is constant evolution within the application. The client goes back and forth with their developer tweaking the application until its completion. The benefit of this type of scope and path is that it is usually much more cost effective, and as you watch the application progress, you realize efficiencies that you may not have seen just receiving a fully-scoped project. The negatives could mean miscommunication between your software vendor and yourself, as well as the cost rising as you start to request more and more functionality.
A full scope is a complete road map of the project from the first blueprint to delivery of the application. These scopes start the same way in terms of conducting fact finding meetings, however they require many more meetings, which are extremely thorough in nature. An extremely detailed scope is produced, laying out the finest details of the application, from functionality to how visuals will look, etc. These scopes can be dozens of pages long and can take many hours to create. The main positive of a full scope is that you have a complete blueprint of how the application will work as well as timelines, checkpoints, etc. Further, a full scope all but eliminates the blurriness of a project. This means you know exactly what you will be getting at the end of the day. It also eliminates the questions surrounding “scope creep”, meaning the application does not change functionality as it is created. While it is possible to make changes during development, it is a much more documented process with formal approvals required. The negatives are that a full scope typically costs much more before the project even starts. Time spent scoping is billed, and, given the length of the scope created, it can be quite costly. Combined with the increased time spent to change or modify the scope and then have it fully approved by both parties, costs can rise quickly.
Long Story Short
- Much more cost effective approach.
- Time can be spent programing as opposed to writing a lengthy scope document.
- The application can be modified and efficiencies added as development progresses.
- Efficiencies can be uncovered, and added, as you see the application progress.
- Approval for changes or modifications are much more casual, as opposed to having to fill out very specific requests. In a full scope, these changes are REQUIRED to be in writing and very detailed.
- Room for misinterpretation between your organization and the custom software vendor.
- The uncovering of efficiencies as the app is built, while it would do more, it could also cost more than your original budget, meaning a blurred line for “scope creep”.
- There may be items you take for granted that may have been built in boxed applications you have used but may not have thought of for your own app.
- When members of your staff, who may or may not be budget conscious, realize they can simply pick up the phone and watch an application change their work day before their eyes, it can literally be like an “addiction” where requests cause the budget and timelines to increase beyond what you originally had anticipated.
- No perfect road map to lean on to state what will and will not do.
- Gives a detailed road map of timelines, visuals, and operations of the application.
- You have a clear document to lean on and a transparent view of what the end result of your application will look like and how it will operate.
- Removes the back and forth between your organization and software vendor as everything is clearly defined in the document. In essence, it clearly defines what we call “scope creep”.
- The cost of the project can be 20-30% more as the scopes can take a lot of time to create.
- If you decide not to go with a project because of cost once scope is written, you are still required to pay for the scope creation itself.
- Making changes to the scope is a much more lengthy process. Everything has to be in writing and takes longer for both sides to approve. This process can often slow down various timelines.
Depending on the nature and complexity of your custom software, choosing which scope framework to follow can be a tough decision. Every organization is different, with different team members, different budgets and different needs. As usual, communication is key, both within your organization and with your developer.