Introduction
In his legendary business book The 7 Habits of Highly Effective People, Dr. Steven Covey lays out his second critical habit that immediately resonates with custom software developers and project managers like us: Begin With the End in Mind.
To quote Dr. Covey, “To begin with the end in mind means to start with a clear understanding of your destination. It means to know where you’re going so that you better understand where you are now so that the steps you take are always in the right direction.” As custom software developers and project managers, we couldn’t agree more. For companies like AppIt that develop mobile apps and web apps, project scoping and requirements definition are critical to any successful engagement. Period. Full stop.
Yes, it may sound a little “our way or the highway” when it comes to these two aspects of the development process, but with good reason. In our experience, potential clients who want to press ahead without fully addressing these critical components run the risk of jeopardizing not only the success of their project, but also of negatively impacting their company overall—not to mention the app developer as well. No respectable, ethical development partner should ever compromise when it comes to insisting on clearly scoped projects with well-defined requirements. At AppIt, it’s nonnegotiable. #dealbreaker.
Yes, It’s That Important
In our experience, here are the top five reasons project scoping and requirement definitions are essential to success:
1. Clear Direction
To be effective, developers need clear direction. Without it, speed is almost always immediately impacted, with developers having to interrupt what they are doing to ask questions, seek clarity, or request guidance. Then, they have to shift from problem-solver mode back into a development mindset while incorporating the new information they have just learned. Lacking a readily available solution, a developer may take creative liberty with writing code to fill in the gaps left by requirements, which may result in diminished quality or an app that doesn’t accomplish the business goals.
2. Quality Assurance
Clearly defined scope and requirements allow quality assurance (QA) personnel to test for proper functionality. Test cases and acceptance criteria are built directly from clear requirements. The clearer the requirements, the better the testing criteria will be and the smoother the QA process operates. This helps ensure costs at the end of each project are contained.
3. Illuminating Obstacles
When these two steps are done well, they highlight potential technical roadblocks early on, saving time, money, energy, and angst for everyone involved. There are times when features or functionality are either impossible, impractical, or may have negative impacts further downstream in the development process. Clear requirements help uncover potential issues early, which is exactly when you want to discover them—when they are avoidable and/or cheap to resolve or work around.
4. Accountability
Clear requirements infuse both the development team and the client with shared accountability, especially on larger projects where multiple team members are involved.
5. Defined Timelines
Clear requirements are essential in the establishment of project timelines. One cannot hope to know how long something will take without them, especially if an app is part of a larger marketing strategy or launch initiative where there are even more moving parts beyond the app project itself. For instance, how can marketing and sales teams be expected to know what to communicate with customers when the timelines themselves are vague or nonexistent? Clear requirements protect timelines, especially for critical launches.
Always Essential, Not Always Easy
Project scoping and requirements definition are critical to project success, but the process of securing them is not without an occasional speed bump or two. Even so, clients, teams, and projects will reap the rewards of overcoming every obstacle that stands in the way of clear scopes of work and well-defined requirements. Here are a few challenges we sometimes encounter.
1. Lack of Alignment
Various stakeholders can sometimes have competing needs and visions for a project. These must be balanced against the three constraints of every project: timeline, cost, and features.
2. Lack of Vision or Foresight
It’s very difficult to describe in words something that doesn’t yet exist. It’s also incredibly important to think through the various ways a user might interact with your app and/or those things they want or need from your app. The most common source of missed requirements is the tendency to only view a mobile app or web app through what we call “the happy path”; the simplest/fastest way through the application. Another common source of missed requirements is a lack of understanding or context relative to how the application will be used in in the real world.
3. Failure to Adapt
Many times as scoping and requirements gathering progresses, new or different information comes to light which can result in changes in the flow or updates to those requirements. These updates can cause conflicts in technical design or other areas of the project that necessitate an “adapt, adopt, and improve” mindset—keeping in mind we are continually managing for results in terms of the stated business objectives.
Defining Project Scope
Every custom software, mobile app, or web app project must begin with the end in mind. Or, put another way, it all starts with business goals.
Identify Objectives and Constraints
A great way to begin is to ask yourself some direct and fundamental questions. What is this app intended to accomplish? What is the revenue impact (increase in revenue or decrease in spend)? What are the timeline drivers associated with this project? Is there a public-facing launch? How much money is available? Where are those funds coming from? Something to keep in mind: the business goals tend to drive the brainstorming for the feature set, whereas the money and timeline constraints put natural boundaries around what can and should be built.
Collaborate with Stakeholders
At AppIt, we stress to team members that there are two main sources of professional conflict: competing priorities and differing communication styles. We also believe that diverse teams produce the best applications because differing opinions highlights the varied needs that diverse end-users have for an application. It all adds up to a healthy and necessary tension that needs to be actively managed in order to generate the best possible results.
Establish Scope Boundaries
We leverage our two primary constraint drivers (timeline and budget) to set clear boundaries, iterate on the feature set, and prioritize those features that are most likely to accomplish business goals. By viewing differing or competing priorities through the lens of our natural project boundaries, we are able to communicate effectively with various stakeholders and brainstorm potential solutions. All prioritization and debate is guided by the primary needs of the end-user.
Conduct Feasibility Studies and Risk Assessments
Typically, before a client invests in building a custom app with us, they’ve already confirmed product market fit—either through existing workflows, a proof of concept, or prototype. In addition, a feasibility study can help confirm their preliminary findings or, in some cases, can illuminate blind spots in time to address them before production commences. Feasibility studies can range from as simple as surveying a key customer group through focus groups or UI/UX research, to more complex approaches such as hiring a dedicated firm to engage in complex, wide-ranging research across industry and markets.
Comprehensive Requirements Gathering
Now that you have the “why,” here are some helpful nuggets about the “how.”
Involve All Stakeholders in the Process
First, set the tone of the entire project by including all of the stakeholders in the requirements gathering process. This goes a long way toward minimizing confusion and mitigating conflict. Start with clear definition of the business goals, as this drives the creation of the feature list. Then, acknowledge the constraints of timeline and budget. Begin all stakeholder meetings with a quick summary/review of the business goals and constraints so everyone—even from their varied and competing viewpoints—can brainstorm and debate with the same goals in mind.
Employ Techniques Like Use Cases, Prototypes, and Mockups
At AppIt, we combine technical requirements gathering with high fidelity designs, sometimes called mockups or prototypes. If a picture is worth a thousand words, a designed prototype is more like a well-stocked library—a helpful tool that gives stakeholders something to react to and brainstorm around. This is why the AppIt team prefers high fidelity designs over wireframes. They allow stakeholders to view a concept that closely mimics what the finished product will look and feel like, helping them to visually empathize with the end user. This, in turn, helps limit the debate around design to how it meets their needs and what adjustments can be made to items within the boundaries of timeline and budget. Tools like these help protect timelines, minimize rework, and control costs.
Ensure Traceability and Clarity in Documented Requirements
Because AppIt serves clients in a variety of industries using several different tool sets, we document all requirements and test criteria in a spreadsheet. A single person is responsible for writing and updating requirements and is accountable for maintaining proper version control. Changes and/or updates are documented alongside the original requirement, helping to instill confidence in decision making as the project progresses.
The Role of Requirements in Project Planning
If you are a project manager, well-defined requirements make your job, your life, and the lives of your clients and coworkers a lot smoother and a lot less stressful. The right tools in the hands of professionals can spell the difference between t-r-i-u-m-p-h and t-r-a-g-e-d-y for your project.
Estimating Timelines and Resources
For many projects, AppIt utilizes a blended waterfall/agile approach. This means waiting to begin development until technical requirements and designs are complete. Once the technical requirements are complete, our development team estimates each user story and builds a sprint plan to maximize productivity and streamline delivery of interim builds per a preliminary timeline. This approach allows the client to test and confirm we are on the right path. Each user story is estimated by the level of effort and associated hours required taking into account the project timeline constraint—especially if there is a public facing launch, in which case we adjust staff resources in order to deliver all the required features on time.
Defining Acceptance Criteria
Acceptance criteria provide explicit instructions to your QA team on what success looks like for a specific feature.
For example, the technical requirement for login would be to have a username and password. The username would be set by the customer and would have the requirement for one capital letter and one number, but no special characters. The password requirement would include at least eight characters, one capital letter, one number, and one special character. Additional requirements might specify that the password can’t be a duplicate of the username and that it must pass a password strength test.
The acceptance criteria might also require that in order for that feature to pass testing, the tester would utilize specific username and password credentials to successfully login as well as some other combinations that don’t meet the technical criteria. Establishing proper and detailed acceptance criteria early on will result in a streamlined, rigorous testing period, which will ultimately serve successfully meeting the overall project timeline. Poorly defined or vague requirements or acceptance criteria result in wasted time, confusion, and delays...especially at the end of a project.
Managing Changes and Scope Creep
Managing change is part of our business, whether it shows up as a beneficial, affordable pivot in the feature set or as it’s subtler, less welcome cousin, scope creep. The good news in either scenario is that when you have clearly defined and agreed upon scopes of work and project requirements, you are free to adapt, adopt, and improve OR be the hammer as the circumstances dictate. Either way, you’ll find yourself able to pursue the client’s goals with confidence, approved documentation in hand.
Point Taken
Given that my goal for this blog is for you to fully embrace just how important project scoping and requirements definition are to the success of any software development project, I hope you’ll appreciate that I followed my own advice (albeit borrowed from Dr. Covey) and started with the end in mind. The big takeaway is this: if you want your project to finish well, you need to start well—by clearly defining scopes of work and requirements as your guides.
At AppIt, we believe so strongly in technology’s potential to enhance client impact and improve people’s lives that we are willing to share in the up-front risks of development. We also believe clients should not only include this approach in the scope their projects, but define it as a requirement for engagement.
