The projects Krumware works on can start in many ways. Sometimes, a client might have an idea they need help implementing. Maybe a client just knows they need to innovate in technology, but they're not sure where to start. Sometimes our employees come up with ideas or we identify a need internally. The concepts for a project can come from anywhere.
The Planning Stage
Regardless of how we arrive at the basic concept for a project, we execute on projects with a workflow that finds a balance between structure and creativity. We have two main goals when starting a project which we accomplish with two separately scoped planning documents.
The Project Abstract
Our first goal, and perhaps the most important, is ensuring that the project accurately represents the needs of the client:
- Is this project necessary?
- Do we have a full understanding of the problem that the project aims to solve?
- Do we know who this project will affect?
To answer these questions, we start by writing a Project Abstract. This document identifies at a very high level:
- What problem the project solves
- How the project can solve the problem
- What technology areas the project involves
- Who the project will affect
Once this document has passed internal review, we share it with the client for review, making any changes necessary until it is approved.
The Project Specification
Our second goal is to ensure that the project is completed in a timely manner:
- Do we know what completion of the project will look like?
- What external factors are required to complete the project?
- Are there potential components of the project that we are tabling for future projects?
The Project Specification aims to answer these questions. This document takes a deeper dive into the "how" which we outlined in the Project Abstract, while still allowing for creative freedom during implementation.
The main purpose of the Project Specification is to define acceptance criteria, so we have a clear finish line for the project. This is very important to ensure that the project doesn't slow down due to unexpected issues and ideas.
To do this, we define Functional and Non-Functional Requirements.
Functional Requirements define how a project will behave, including features and functionality. This is the important section for making sure the document is specific enough to fully encompass the project. Functional requirements can be used to distinguish between correct and incorrect output.
Non-functional requirements define constraints on the operation of the product and project.
- Non-functional product requirements might be something like reliability, device compatibility or response time.
- Non-functional project requirements could relate to tools, programming languages, or development methods.
While this may feel like following a more linear project management methodology, we maintain flexibility during implementation by keeping our requirements at a high-level. As a general rule, we only define requirements which we have a high degree of certainty on. Though requirements can change during the course of a project, the goal of a good Project Specification is not to change. Rather, the requirements should walk the line between being general enough to account for change and specific enough to ensure that the client's needs will be met if the requirements are met.
Our Requirements can get a little dense and difficult to sift through, so we also define Use Cases and Deliverables. Use Cases allow us to tie our requirements back to the real world application of our project and Deliverables group our requirements into logical sets. This allows readers of our Project Specification to easily identify the major components of the project at a glance.
Once again, this document goes through internal review and is then shared with the client for review.
Results
The Planning Stage ensures that both Krumware and the client have a strong understanding of the project as a whole before work even begins. As part of our collaborative strategy, we want the client to be deeply involved with the project. The documents we create during this stage serve as a roadmap which will allow those with a non-technical background to understand the direction and vision of the project while also allowing those with even just a little bit of technical knowledge to contribute in meaningful ways which push the project closer to the finish line.
What's Next?
Once the Project Specification is approved, the Planning Stage is complete and we are ready to move into the Implementation Stage. We'll discuss what goes into a successful Implementation Stage in a future blog post!
