RSA Archer lends itself particularly well to an “agile” development approach. A lot of the implementation work we do in Archer is configuring, instead of coding from scratch. We can work quickly, present it to a customer for immediate feedback, and then make changes and keep moving forward on a project.
But an agile approach doesn’t always meet the standards of auditors or internal project PMO’s. They’re used to a traditional waterfall approach to project management, where each stage in a project is distinct, and each stage ends before the next begins.
What we’ve developed is a hybrid approach that brings the best from both worlds. We have five steps – or gates – in the process that serve as milestones and sign-off points, keeping project accountability intact. Between those gates in the design/build stage, we use an agile method to guide our development.
Once a Statement of Work is signed, we work with our client to develop a Business Requirements Document (BRD). This document clearly details the business challenges and company needs that the project will address. The BRD gets reviewed with the entire project team, and signed off on by the project sponsor. It’s important to keep the BRD focused on business. It’s not about defining an end-state solution, nor is it the place to capture design details for documentation.
The agile approach really comes into play during the design/build stage. We constantly develop and refine, and get continuous feedback from the customer to make sure we’re matching their expectations. These refinements and feedback reviews are known as iterations and can occur as frequently as weekly. Typically we would have a set number of iterations scheduled to meet project timelines; however, these are frequently adjusted as required.
When it comes to change requests, only business requirement changes or significant design changes need to go through a formal process. In other words, changes that affect the timeline, scope, or cost of the overall project. Any other change gets documented and logged, allowing development to keep moving ahead while ensuring we’re aligned to the original business goals.
During this stage all technical design gets documented in the Solution Design Document. This document maps back to the BRD and illustrates how each of the business requirements were met. It’s not a technical or user training guide, nor is it a test document — but it can form the basis of one.
Next is the User Acceptance Sign-Off, indicating that the production candidate is ready for implementation. That’s followed by the final gate, Project Closure. This last gate is often skipped, but it’s important for many enterprises at the end of the project to make sure that the charter, requirements document, and all appropriate signoffs have been received, along with a final check that all the requirements have been met along the way. It’s also a chance to gather “lessons learned”, document any known issues, identify elements that are out of the scope of the original BRD, and suggest future steps and projects.
In summary: The hybrid agile-waterfall approach really is the best of both worlds. It makes auditors and PMOs happy because they can see the gating process that they’re used to. It also allows our production services team to do a lot of build in a short period of time, keep the work very closely aligned to what the customer wants, and keep the project moving forward on time and on budget.