Scope is really just a fancy term for the list of things you want this project to accomplish. This might be referred to as deliverables, milestones, goals, or other words that capture the essence of the whole reason why you want this project done. Scope can be as small as just a point-form list, or as large as a full brief.
How to calculate a baseline
Estimates are the burden of many developers. But they don't need to be complicated. Just start with the absurd: should this take a year? A month? A week? A day? An hour? Sometimes just working with basic units of time makes it easy to narrow down a reasonable estimate, and that's all you really need as a starting point. You can refine the details later.
Quantifying your tasks
The most important part of the quantifying step is to break down your high-level tasks into manageable sections so that you have a clearer picture of the full set of deliverables.
How to normalize tasks
Normalizing involves expressing multiple tasks in a standardized manner so that they are on equal terms with each other. If some tasks have high level estimates like 'a month' while others are more specific like '20 hours', it helps to express all of them in hours, so that a month is actually 240 hours (for 30, 8-hr days) or 176 hours (for about 22, 8-hr days). It can also help to break down tasks into equal-sized, smaller tasks, if you can identify, say, 8-hour chunks for each main task.
Setting a priority
This can be as simple as classifying a task as a priority versus not a priority, or you may want to be a little more specific like identifying a risk and reward matrix. Other methods like high, medium, and low, or even a numeric priority will work. Whatever method works for you or your organization is suitable, but it's good to have some kind of picture of which tasks are more important than other tasks, as far as the business is concerned.
OUTPUTS
insert_drive_filePreliminary Scope
calendar_todayEffort Estimate
thumbs_up_down
Qualifications
INPUTS
highlightPreliminary Scope
Determine necessity of scope items
This is where you assess how important each scope item really is to the success of the project. Most items should be either a must-have (required), should-have (preferred), or nice-to-have (optional).
Determine the key people
At this step, you should be able to identify most, if not all, of the key people who will be primary implementers on your project.
Find out what you don't know
This is the opportunity to outline any aspects of your project that are based on presuppositions or assumptions, and which should be validated in order to reduce the overall project risk.
Find your order of operations
This is where you determine which tasks should generally be done in which order, or which should be grouped together. Unlike importance which determines the make-or-break scope items, urgency determines which basic scope items should be completed before others for logistical, organization, or strategic purposes, regardless of the item's importance.
Define hard deadlines
Deadlines need to be taken seriously, but should only be classified as a deadline if the success of the project is dependent on the deadline. If a date is capable of being moved, then it shouldn't be classified as a deadline.
Determine your action plan
Without overcomplicating the plan for your project, this is where you should determine which management method should be used for overseeing your project. This will be methodologies like waterfall, or various agile approaches, or whatever method is suitable for your project or organization.
The first step of the active part of the project is to spend as much time as possible dreaming about the potential solutions and ideas that would be suitable for all of the main scope items. It's not a bad thing to dream a little further outside of the scope as well, since this can help to frame future potential and steer the current development needs in the right direction.
Compile your scope into a manageable structure
Using data from your importance and urgency estimates, organize all of the additional ideas you came up with and determine which items fulfill or partially fulfill the main scope items. For the ones that don't fulfill, don't be afraid to just set them aside, but keep them on your radar to help frame your architecture later.
Cross your Ts and dot your Is
This is the time to scan through all of the primary scope items, plus the newly added items from brainstorming, and identify any missing gaps that need to be solved out before proceeding. This will involve expanding your tasks into more detailed lists, and identifying anything else you need to accomplish the project.
OUTPUTS
insert_drive_fileList of Requirements
zoom_in
Analysis
INPUTS
insert_drive_fileRequirements
Prepare summary for stakeholders
The purpose of a business scope or a business charter is to outline the primary goals and outcomes expected for a project and to identify the communication strategy on how you as the project manager will provide updates on the progress of your project to the owners and stakeholders.
Cross your Ts, dot your Is
The proof of concept might be proof that something can be done, or just an implemented sample to give a guideline to developers on how something should be done, so that you can implement more fully later in the process.
Make sure the requests are legit
This doesn't need to be overly complicated and can simply be a checklist of affirmations where you confirm that the requirement is possible, achievable, and reasonable as a solution for the scope item you were trying to solve.
Identify what really needs to be done
The project scope is a more detailed version of the original scope that was identified. The project scope needs to include any additional proof of concept items, requirements, or identified solutions that are needed in order to accomplish the project. It includes both the business outcomes and the technical outcomes that are necessary.
Estimate the cost and time
For any budget information, you should keep track of this in a separate spreadsheet so that you can submit budget requests in accordance with your organization's budget practices.
Outline as many steps as you can
It's time to build the final target plan, including the effort associated with scope, quantified and normalized tasks, assessed importance, identified assumptions, and identified urgency of each task as well as any additional gathered requirements
OUTPUTS
insert_drive_fileBusiness Scope / Charter
insert_drive_fileProject Scope
calendar_todayProject Plan
thumb_upManagement Approval
format_shapes
Design
INPUTS
insert_drive_fileProject Scope
Define any rules and procedures you know
In this phase your architects and developers will define use cases and diagrams in accordance with the business requirements. If the idea of a diagram is paralyzing to you, you can always represent the process in a textual fashion by using a sequence of steps in a numbered list, and a few basic if..then statements to identify the control flow.
Set some guidelines for coding
Architects and developers establish the specific inputs and outputs of business use cases to ensure appropriate data is functional in the development cycle. The goal is to convert business inputs and outputs to programmatic inputs and outputs.
Prepare the test expectations early
This is a good time to do some preplanning and to establish at least a few basic test patterns and possible conditions that could occur in the development process so that your developers have some kind of guideline on how to test whether or not their function works.
Prepare the data and core structures
Conceptual models are programmatic representations of data models or operational components. These can be expressed as either text descriptions, or you may wish to use a more detailed UML class diagram. If you are developing an object-oriented solution, this is your opportunity to draft basic functional classes with non-operational methods built in so that you can get a feel for the overall organization of your software solution.
Outline the sequence of steps
You should use your business use cases as a guideline and work with your architects and/or developers to define some step-by-step requirements for specific coding deliverables and establish any critical operational logic that is necessary for your business requirements.
Prepare a draft of how it will look and work
If your application has a heavy UI or UX component, this is the time to establish the interface wireframes that are necessary to provide end-users with an easy way to control the business logic of your application. If you have an application that is not UI-heavy, like a public API, you can still design a type of interface wireframe by establishing any necessary patterns for your API that will give some kind of visual insight into how it works.
Verify that the design matches the need
All of the people responsible for the design and development aspects of your project get together and review all of the previously prepared documents—the project plan, use cases, development parameters, conceptual models, business processes, and wireframes—to confirm them for accuracy and feasibility in development.
OUTPUTS
settings_applicationsUse Cases
settings_applicationsModels & Processes
insert_drive_fileArchitecture
thumb_upManagement Approval
Development
domain
Organizing Architecture
INPUTS
insert_drive_fileArchitecture
calendar_todayProject Plan
Establish a baseline for the primary app
The single most valuable skill in learning to master the art of translating architecture to code is to perfect your documentation. Like any other skill, you only master it by practicing it, so it's important to just document everything you can.
Start drafting your code
This usually involves drafting initial iterations of your code structure, creating interfaces and abstract classes, initial hierarchies for SASS or LESS structures, variable naming and documentation standards, and the like.
Prepare initial files and boilerplate code
A great opportunity to start building any major templates, especially for web applications, and similar objects like web components, UI guidelines and designs, or any requirements associated with your application's overall code structure.
Start detailing your code
A more detailed iteration of the above, this is the tine to create objects from your interfaces and abstract classes (in an object oriented environment) and frameworks for your functional logic so that you can fill in the blanks with functional code when you're ready.
OUTPUTS
insert_drive_fileImplementation Architecture
insert_drive_fileTemplates & Patterns
codePseudocode
insert_drive_fileDeveloper Docs
code
Building / Coding
INPUTS
insert_drive_fileDeveloper Docs
Connect business processes to your code
Start tying in your functions and classes by creating the necessary sequences of operations and testing functions in practical settings, to confirm the overall operation and execution of your application.
Write the meaty parts of your code
For all of your functions and classes, finalize the operational code that will work on real data and return real results.
Prepare test runs
For any automated or manual testing that you do, run tests on your code for confirmation of its operation and general flow. Be sure to test against the expected outcomes of your application.
OUTPUTS
codeCode
settings_applicationsTesting Environments
feedback
Reviewing / Testing
INPUTS
calendar_todayProject Plan
Review all your documents
Review the documentation, both inline and standalone, and verify that either the code implementation matches the documentation, or that the documentation was updated to match whatever code changes were suitable.
Verify the operation of every routine
Verify that your functions are actually returning the data you expect under the conditions you are working with. This is really just another standard phase in the coding process, but we track it as a separate project management item because it's always good to identify that you've explictly gone through and tested each of the core functions.
Benchmark and test for reliability
Using benchmarking tools as appropriate, or validations of runtimes against operational requirements, verify that your code is performing in a manner that is functionally suitable for the target audience.
Ensure the code is valid to specs
Use basic tests like unit tests, edge case tests, scenarios and mockups, to test that each function or major operation is performing as expected, and returning the anticipated results.
Ensure the code integrates with other systems
Verify that the implementation of your application will work as expected in a real-world environment. This might mean integration with a web application, libraries added to existing platforms, and other similar tests.
OUTPUTS
insert_drive_fileTraining Reference Drafts
Testing & Deployment
cloud_upload
Staging
INPUTS
settings_applicationsSource Control Builds
insert_drive_fileProject Scope
insert_drive_fileDeveloper Docs
Give yourself a sandbox
If you don't already have a development environment to run simulations and functional tests in, take the time to set up that environment, and deploy your code. Using nightly builds or integration solutions, you can auto-compile and deploy your code to an alpha environment where you have the freedom to sandbox your application and verify its operation.
Give everyone else a sandbox
It never hurts to add a second testing zone where your alpha code is deployed to when it passes your alpha tests. This is also a great place to point your users (particularly internal ones) for internal user testing. Continue working and deploying to alpha, but only deploy to beta when you're ready for others to start testing.
One final check before production
Having a staging environment can help to ensure that you can not only test your application in a perfect production environment, but you can also set up servers and structures that are needed for production so that you can remove a production server and replace it with a staging server when you're ready to go live.
OUTPUTS
settings_applicationsStaged Applications
settings_applicationsRelease Candidates
how_to_reg
User Acceptance
INPUTS
appsFunctioning Applications
Verify that you did what was asked
Take the time to work through the application with your users and verify that it meets their expectations. In the end, you are looking for their acknowledgment that the application works for them.
Get everyone to sign off on your work
Verify with stakeholders that the application does indeed meet the requirements established at the beginning. Ideally, you will have been doing this all along through the coding process, but this a final opportunity to validate the end result.
OUTPUTS
none
school
Training / Deployment
INPUTS
insert_drive_fileTraining Reference Drafts
Teach others how to use what you built
Prepare any final written documentation that is needed for users to ensure that they have everything at their fingertips for using your application properly. If you are creating an application that requires user deployment, rather than server-side operation, make sure the documentation includes full installation and troubleshooting instructions.
Verify that you've produced a functioning app
Verify that the final application has been deployed, either on servers or on user workstations, to ensure that the end result is actually ready for production.
Publish, and make it live
Have a party. Celebrate the delivery of a product, especially if it's on time, to scope, and within budget.
Check back on what you've done
It never hurts to have follow-up meetings after the application has gone live to ensure that it continues to meet expectations. Most importantly, you want to review the project process overall and verify that the process you followed was beneficial to the stakeholders.
Look ahead to future requests
Undoubtedly there will be bug fixes, enhancements, or feature requests, as well as several carryover tasks that needed to be cut from the intital scope or postponed because of scope creep. Take time to finalize the documentation on those items and set them up for future projects.
Shut down the project
Close out this project, making sure that any future project requirements or maintenance schedules are already in place and ready to be built out.
OUTPUTS
insert_drive_fileTraining Documentation
calendar_todayProject Status Report
calendar_todayFuture State Project(s)
thumb_upStakeholder/Sponsor Signoff
Maintenance & Growth
contact_support
Support
Keep others in the loop on changes
As yoour applications continues to grow and enhance, you need to keep your documentation up to date, which also means continually supporting the users in ongoing training.
Fix everything, as you can
Make sure you follow a consistent schedule for resolving ongoing application bugs. Don't assume that you can make time to fix them once you have a critical mass of bugs. Always assume that you need to set aside time regularly, such as weekly, to resolve issues. If you have no issues in any given week, concentrate on enhancements and new features.
build
Maintenance
Verify that it's always working
Regardless of what kind of application you build, there will always be changes to the environment such that you need to reevaluate the software's operation. It might be an OS change, library updates, language changes, or even the addition of new hardware on which the application resides. Keep testing regularly to ensure the application continues to meet expectations.
Validate against competing solutions
Whenever possible, take time to compare your bespoke system with other off-the-shelf products. It might be reasonable to assume that a custom-built application will be replaced by a more robust system that works out of the box for your organization. Being prepared for that possibility ensures that you are ready to transition should the need arise.
trending_up
Growth
Continue to improve what you've done
When you're not fixing bugs, schedule explicit time to iterate through the incoming enhancement requests from your organization. Setting aside time to make changes helps to keep you in active communication with your users, and meets their needs.
Continue to build more into your system
Just like enhancements, set aside even more time to functionally improve your application with completely new features. Some of these may be more complex, and might necessitate a project of their own.
Maintain a good to-do list
Maintain an ongoing backlogging system so that it's easy for you to keep track of incoming requests and respond to user input.
Identify major release opportunities
You won't always be able to concentrate on every enhancement or feature request on a regular basis, so it's good to have a less frequent review process, with your users and company leaders, to solicit feedback on long-term goals and visions for the application you've build.
Schedule explicit application updates
Take time to schedule regular releases, even just for bug fixes, so that users will know what to expect when changes roll out.
Continue to promote and support
Keep a long-term vision handy for how you'll communicate about your product, not just for minor updates, but also major improvements. Communicating regularly about the application helps to keep general user interest in your system, and maintains your credibility as an expert supplier for the system.
Continue to train and advertise
If your application needs public exposure, it may be wise to invest in professional training material and marketing for your systems, especially if non-employee users will be regularly using your system.