Importance of Functional Scope, Technical Scope & Blueprint Deliverables
There are many definitions of a “scope” in the tech space and, in turn, many explanations of how a scope should be done and what a scope should contain. As with many companies, a lot of how a scope is created or discussed is highly dependent on its culture and production capacities. Some companies cannot fully justify the time it takes to get a proper scope (whether a functional scope, technical scope or any blueprint scope phase) and often skip what is considered to be one of the most important aspects of initiating a project with a new company. In this article, we want to discuss what we feel are key components of a project scope, technical scope, or blueprint outline, its role in successful mapping of custom website and application development, and methods of incorporating this practice into your company’s process.
What is a Project Scope of Work?
A scope of work should serve many purposes, but one of the most important aspects of a scope is creating clear and realistic expectations between both the client and the team executing on the development of a project. In contrast, a poor scope could result in unhappy clients and often lead to delays, miscommunications, and overall less efficient processes. In much the same way a hunter uses a rifle scope to zero in on their target, a project scope is a tool to zero in on the specific purpose of a custom development project. A scope of work should “aim” to clearly identify functionality, architecture, user journeys and UI/UX in a way that is understandable by all stakeholders on a given project.
What Else is Included in a Project Scope?
The process of creating a project scope is not just planning and writing. There is a wonderful aspect about the early stages of a scope that is often overlooked and undervalued. When creating a project scope, this process typically takes several blueprint meetings if not even several day-long workshops to complete the learning phase. At Crosby Interactive, we call this phase our “Blueprint Phase”. During this phase of a project scope, we often find that not only is the technical knowledge we receive incredibly valuable, but the conversation and interactions with the clients also serve to nurture the relationship between both parties. After doing several blueprint workshops with many clients, we have learned that one of the most valuable aspects of these meetings is establishing the “soft” points of the relationship early on. These soft points can be found below.
In all stages of a project, communication is key. It is often the case when communication is lacking that a project can stray wildly off course and expectations become less aligned between both parties. In our blueprint meetings, we often make it a key point to establish certain protocols for communication. Examples of these would be:
We prefer single compiled emails over many one-line emails outlining individual items.
Other Types of Communication
Some companies use only emails to communicate while others prefer more modern tools such as Slack, Skype, or Google Hangouts.
When building a project, transparency goes a long way for both sides involved. In one light, having the client highly visible at most stages of the build process allows them to provide feedback in a focused manner. In the other light, it keeps the team working on the project highly aware of what is at the forefront of the client’s mind for that week or even that month. Involving clients in the build process from an agile perspective will allow issues and concerns to be addressed in an organized manner.
Another key component that is often taken for granted is establishing a common nomenclature. Basically, this is mapping out and identifying common terminology used to describe business features, components or functionality. Often referred to as a Glossary, in many projects we have been apart of in the past it is often the case that you will find either party using different terms or words to describe the same thing. This inherently leads to confusion on both sides as each term or word is often associated with a core list of functionality and expectations.
A good example of this would be a User vs. a Member vs. a User Account and so on. In complex systems, developers and stakeholders often have specific implementation around these terms and if the nomenclature is not outlined and agreed upon, you may find that a feature you thought was supposed to go on the User Account system is now in your Membership system while that was not the expectation.
Primary Stakeholders and Their Role
In many cases when building a relationship with the client, you will find that there are members of both sides who may be well versed in a specific topic or business functionality. We refer to these individuals as stakeholders. Stakeholders are often the primary checkpoints for confirming accuracy of a particular feature, functionality or even entire modules. Identifying these stakeholders early on will often allow Project Coordinators to designate key pairings, or “micro teams” in meetings and standups to allow for more focused and efficient conversations which will, in turn, create optimal outcomes.
Technical v. Business Expertise
Project scopes are not just for technical purposes. Scopes also allow a chance for the business to be strategized or even re-thought entirely before a build even begins. Often times, we find that for as many organizations who have figured out all points of their business and strategy, there are an equal amount of times where the strategy and business concepts are non-existent and are, therefore, crafted out of these blueprint meetings. We love these meetings for that purpose, providing more value than just being the vendor allows us to think in terms of what is best for the client overall.
What Does a Scope and Blueprint Template Look Like?
Scopes can exist in all shapes and sizes and many scopes are often not exactly like the last one created. But for sake of aggregating our thoughts into a list, here are three major categories that our scopes can fall under:
In development specifically, it is safe to say that EVERYTHING should be scoped, but that is not always the case in every situation. Sometimes, things like budget, timeline and even resources can dictate how much effort will be invested upfront in a project. But other times, there is just less in terms of functional expectations and more in terms of design and marketing. We can safely say that, for as many highly technical projects we have worked on, there is an equal or greater number of projects where the client just wants you to build a simple site, throw some design and marketing content in and “get it live.” These projects are often the ones that end up being the most exhausting as without clear definition of expectations upfront, the end result can be completely on point or sometimes wildly different than the original idea.
In large custom development projects, we see the scope and Blueprint Phase as being a necessity. There is no way to build a completely custom system without clear understanding of all aspects of each system or component being delivered. Items such as functionality, architecture, user interface/experience and database design are all crucial in dictating the outcome of the project and need to be understood by all parties before a project build should begin.
The final category is a combination of the first two categories and probably our favorite. These are typically brand new projects or products that are being designed, strategized and marketed from scratch. At Crosby Interactive, we truly enjoy working on projects where we are considered partners rather than vendors. In our blueprint workshops, we are often key in rethinking business strategies and and functionalities and, with that, we become highly aware and involved in overall business goals and expectations from day one.
What is Delivered in a Scope or Blueprint?
At this point in the process, you may have been through several day-long workshops, including several members from both parties, and countless emails, approving or revising mockups and wireframes. What does the end product look like?
Although this is a full list, projects can and will differ on what items are included in the final deliverables of our Blueprint Phase.
On heavier technical projects, this is hands down the most important document. A well written Functional Scope can dictate every single one of the other documents delivered during this phase. To that point, it could be almost impossible to create finalized versions of the other documents in the Blueprint Phase without this document being complete and agreed upon first. We have created functional scopes that range from a single page to close to 50 pages which should give you an idea of how much effort it takes just to get this one document completed.
Although seemingly less understood, the technical scope specification document is important in its own right. A well-written technical specification document can save much time and onboarding efforts when dealing with internal IT teams, 3rd party integrations and other technical vendors. Without a clear understanding of the technical infrastructure, it could be more difficult to identify when aspects of the systems used will need to be updated or how additional functionality could be integrated down the road.
Database Architecture Diagram
Similar to the Technical Scope, this is probably more important to the Development and IT teams at the early stages of the project. With this document, development teams can better visualize complex associations within the system and understand potential bottlenecks or areas of poor design much easier before realizing it later in the build and being too deep to make the proper adjustments.
Wireframes and Mockups
Let’s be realistic. Most people are visual in nature when it comes to absorbing complex ideas. Any chance you get to visually represent an idea, the more likely that your vision will align with the outcome. Both mockups and wireframes in a project scope are key to doing exactly that, providing a visual. They can go hand-in-hand with a functional scope and serve as great references when discussing functionality but also set a clear direction for designers and UI and UX development teams. Depending on the complexity, you could easily require several, if not hundreds of individual wireframes or mockups.
This is another point where budget, culture and planning all play key roles in this deliverable. With most clients, we try to set a limit or expectation on not only the number of these that are created, but also the number of revisions allotted for each one of these items. It could be very easy for this process to never end without some kind of parameter set to avoid getting caught in these loops. The overarching goal with these deliverables is to get a common idea of the expected functional design and/or layouts and move on to defining how those will work.
Another often overlooked aspect of a well-executed functional scope is the User’s Journey. But what is a User Journey? A User Journey seems to have many definitions across the internet, but we choose to stick to a very simple explanation. User Journeys are the potential paths or flows in which your users follow to land at specific screens or outcomes. With proper User Journeys, not only can you identify bottlenecks and issues from a functional perspective, but you could also identify potential marketing and upsell opportunities that you may have not previously thought possible or even thought of at all. It is crucial during the Blueprint Phase to propose and identify these User Journeys as well as challenge existing ones in hopes of creating an overall better and purposeful user experience.
UI/UX and Branding Guidelines
UI/UX and Branding are huge keywords in the digital marketing space. There are so many interesting ways other companies see this process unfolding for their clients. The primary idea behind these deliverables is to provide design direction for the team building your system and the stakeholders contributing to those designs. Some companies do not already have these items documented and often lean on agencies and teams to craft their identities from scratch. In those scenarios, this document becomes as important as the Functional Scope and Technical Scope. As we stated before, each one of these can vary in scale and importance depending on the type of project being scoped.
Often an afterthought at the early stages of a project is the Marketing Strategy. Sometimes companies have this all figured out and maybe this is the only part they have figured out at all. Other times, we use our blueprint meetings to discuss potential avenues for marketing and lead generation. After all, the purpose of most branded websites is to acquire leads and make sales. Without proper marketing strategies and no path of execution for getting the site or toll in front of people, you will not likely see ROI for a good time after launching your new idea.
As you can see, pricing is an area of the Blueprint Phase that can vary wildly in either direction. Depending on your requirements, we often see the costs of the Blueprint Phase for projects ranging anywhere between $2,000 and $30,000 or more. Factors such as size, scalability, training, testing and so on all come into play when you are planning each one of these components. One thing to consider about the cost as well is the number of billable people on a given project. If you have many hands in the pot you could easily expect to be at the higher end of the range out of sheer employee hours. Despite the sticker shock associated with numbers like this, we have found in our experience that the investment in the Blueprint Phase greatly reduces the costly bugs, refinements and changes that typically occur at the end of a poorly scoped project and can end up saving a client up to three times the Blueprint Phase cost at the end of the project.
We, at Crosby Interactive, treat our Blueprint Phase like any other deliverable and with that, our focus on quality is at the forefront at all times. This is something that requires a lot of time and effort upfront from both parties and must be agreed upon before a project even starts. On top of that, this document will persist possibly long after a project is finished and may be used as collateral to make updates, pick other 3rd party vendors, training and so on. With that said some of the most important aspects to us are:
We are all on the same page and there is a clear understanding between both parties as to what is being delivered. There will definitely be changes as the project progresses but the idea behind a project scope is the final common agreement which allows stakeholders to know what they are expecting and development teams to know what they are building. The end product should be mostly aligned with this final agreement.
Transparency and Efficiency
By delivering our functional scope, technical scope and/or blueprint, we demonstrate our current level of understanding of the system being built before any code is written. If we can put it into words and explain how we intend to build it, it is likely we will be closer to the expected outcome rather than further. By all sides being on the same page, we will inherently be more efficient with our time and deadlines.
This is probably the least obvious point of everything. A blueprint being a deliverable could, in theory, be written well enough that one could take it and shop around for alternative rates. In our experience, 98% of the time this is not the case. Typically, if you have gone this far into understanding a system, why would you pay for one company to “figure it out” but then have another company execute on the building? Most times, the relationship is solid enough and the project scope is written well enough that clients often choose to stick with the ones who created it. Why would you ask Ford to design and specify a car design and then ask Honda to build that car?
In conclusion, project scopes are essential for us at Crosby Interactive to achieve the high quality of work we’re known for. Happy clients and better documentation are also great side effects of project scopes. If this doesn’t sound like something that will fit your use case, then let us work with you. We have experience in working with all levels of complexity and budgets. We understand that you probably still have questions and would maybe like to know more. We would love to discuss our process with you and your team. If you found any of this useful, please like and share or feel free to contact us to start the Blueprint Phase of your next great idea!