This project follows the development and management process established for Atlas. The goal of the process is to provide a simple and transparent feedback loop to translate high level business requirements into implementation tasks. The process consists of:
A product council to provide overall governance. The product council is a group of 5-8 stakeholders drawn from editorial, product development, IT, online, and marketing that guides the overall development of the project. The council meets at a regular monthly interval (i.e., first Thursday, second Wednesday, or whatever) to discuss new business requirements docs (BRDs) and review the schedule for the project roadmap.
Business requirement docs (BRDs) for each system or feature to be developed. Features will be developed only after their business value has been discussed, prioritized, and approved by the council.
A set of functional specs. Once the high-level a BRD is approved, the next step is to develop a set of functional specs that describe how the implementation team will approach the feature. The functional spec may include wireframes, code samples, documentation, prototypes, and other elements. The various elements in the functional spec will be checked into a GitHub repo, and discussion will happen via GitHub issues.
Roadmap tracking via GitHub. Once the functional spec is ready, the implementation team will break the task down into individual milestones, create subtasks, and make assignments. Each milestone has a start date, and estimated time to complete, and a percentage completed to far based on the completion of underlying tasks. This schedule will be visible on an automated project dashboard similar to the one used at IT Steering and the Atlas Roadmap.
Once a BRD is approved and the functional specs laid out, the feature’s implementation can be tracked on an automated dashboard.
It’s critical that this be an iterative process. For example, functional specs will change many times as discovery happens, BRDs might be clarified, or the timing of critical BRD features might be affected by changes beyond the implementation team’s control (as in the example of the timing of the GitLab API). Here are some great examples of discussions around specific functional requirements:
It’s also important to note the use of “implementation team,” as opposed to “development team.” The goal of this process is to involve and coordinate all the parts of the company that are involved in developing and bring a product to market. So, the implementation team might include designers, marketers, SEO experts, outside consultants, or anyone else who has a stake in the outcome of the product development process. Granted, many of these stakeholders may only be involved in certain tasks or sub-tasks, but it is critical for the overall project’s success that each part of the team have visibility into the timeline and clear accountability for completing their tasks.
Finally, the key to success in any large project is clarity around the decision making process and visibility into the current state of work.
