How to Balance Project Agility and Predicitability

A project manager is often seen dancing in the wilderness of scope creep, balancing resourcing constraints on the head of the budgetary needle, dealing with the inevitable boogeymen on the road to integration. Your role as a PM, in short, is to remove obstacles that enable real progress.

A formalized project implementation methodology and accompanying document artifacts, like that provided by Microsoft Dynamics SureStep, help provide predictability and control. The challenge is that typical waterfall based approaches don’t work well on smaller budget projects, or where scope is not well known.

“Agile to the rescue!” is heard over trumpets. Your small army arrives and starts configuring, coding, and generally doing things very quickly. Things are being built, things you can see, that’s progress right? Are they the right things?  When is it done? How do you measure completion without the requirements up front? And how did you sell agile when your client needed a predictable budget?

An agile methodology provides working use cases early and often, and by its nature engages clients directly in the development of a system. These benefits tend to be yielded at the expense of predictability. With clients where you have already established a level of trust you’ll notice that your projects often drift this direction - I think that’s good. Until that trust is established predictability will be important.

Let’s say that your project has unknown scope, or the scope will likely change frequently. Maybe you’ve got a new client, or a tight budget, or for other reasons don’t want to introduce the burden of a complete waterfall methodology. What are your options? SureStep provides a defined agile methodology (see below), based on SCRUM , and while this approach is good, we’ve already established that it requires a level of trust and commitment from your client.

A practical approach to applying SureStep is to follow the methodology, but minimize the document artifacts that need to be produced. Let’s work backwards on a project. One of the last key document artifacts before sign off is the User Acceptance Test script (UAT), produced by the “Conduct Solution Testing” step (3.6.9 in the standard project type, and 3.6.1 in the agile project type). UAT is unfortunately often a rushed activity near project completion, or is sometimes skipped if your budget is shot, or it will sometimes end up as an “as-built” instead of “what-I-wanted”. This is unfortunate as it’s the document that has the most relevance and the most clear document that says: “When I put my initials, dates, and comments on this list of steps, I am agreeing that this functionality works in a way that I have tested it and that is sufficient to meet my needs.” Why is it skipped so often? The UAT document is the realization of your requirements and design documents, so the material by that point has been established. You’ve likely just finished some training prior to the UAT, so the client is already familiar with its workings. If the project budget needs help, this document and its supporting activity are often the easy targets.   

Let’s switch it around. A UAT will contain your core use cases, which inherently contain your important requirements and the user interaction design. Instead of capturing requirements and interaction design in separate documents, let’s define those up front, and build those into the UAT. Requirements that cannot be placed directly into a use case can still be listed separately in a simple table near the top of your UAT. It should help make your implementation team’s lives easier as it provides a clear use case of how the system should work (much easier than a long requirements document, which is often in a language that will engage your clients instead of your implementation team), and it should also make it easier for your clients to visualize how the solution will work.

By applying a test-first approach directly to SureStep, we end up with a model like the one shown below. Incorporating UAT documentation at the design stage of the classic waterfall implementation aligns usability with development goals and reduces the required steps in the implementation process, which still remains predictable and cost-effective. The amalgamated documents can then be referenced throughout the implementation process as a check against requirements.

Where the colors follow the standard Dynamics SureStep phases.

Compromising the predictability of required documentation for the sake of project fluidity may not sound like an ideal situation, but in many cases it can be beneficial to the project. We’ve implemented a similar test-first hybrid model on projects in the past and have found it’s a great way to provide clients with both sound budgeting and project flexibility, all while clarifying their desired usability for our development team.

Tim Dimsdale
Dynamic Manufacturing Solutions