Have you ever been asked to create scoping documentation for an agile development? It's not easy is it? You've probably found that, amongst the many benefits of focussing on customer collaboration over contract negotiation, there are also challenges. The worlds of agile and formal software purchasing don't make for happy bedfellows.
- Agile teams have embraced doing as little documentation as they can to support their development processes and avoiding contract negotiation is actually enshrined in the manifesto.
- Companies purchasing software or development, on the other hand, rely on documents such as specifications and scopes of work to ensure that they are going to achieve the benefits they expect for their budget.
The last thing a customer wants to agree to is buying development sprints on a 'time and materials' basis to see what you come up with, even though in an ideal world that's what you'd want to sell to allow for flexibility and limit your risk. If this sounds familiar - I have good news! Creating flexible but powerful scoping documentation to bridge the gap here is possible - and in this post I'll show one way of doing this.
Some approaches that don't really work
A few years ago I was working for a company that was struggling with client development projects running over at high cost to the business. If we look at their purchasing process it's understandable why. The contract negotiation was run by account teams using beautiful agency produced designs to impress the client. The design process gave no consideration to user experience or practical ability to deliver and so inevitably the development overran with a lot of time sunk into achieving the exact design rather than adding value. In one extreme example a team spent over two weeks getting a smiley icon to change on a mobile slider control as it was moved, even though the users finger would be obscuring the icon during this process - it was in the design so had to be included.
More recently I've had a similar need, though this time the approach being used focused on tightly scoping the technical details involved in the delivery. This was better and provided much more confidence in the ability to actually deliver, but did come at the expense of a clear focus on the user and their goals. The result was an integration that worked from a technical perspective but left the end user with too many manual steps to achieve their tasks, and the customer ultimately a little disappointed.
Focus on outcomes
Despite the different approaches, the challenge in these situations was the same. How to produce documentation that:
- Was robust enough to get it through a contract negotiation or purchasing team
- Provided clarity for both parties on what we were aiming for and a basis for confirming when we were done
- Allowed for flexibility in how to deliver, allowing for undiscovered technical constraints
For me the answer lay in the mantra of high performing teams everywhere
Focus on outcomes not outputs
i.e. focus on what the software will allow people to achieve, rather than on the delivery of the software itself.
(A common example to support this way of thinking is that people don't want a 1/4 inch drill they want a 1/4 inch hole. I personally I find this strange. The last time I used a drill the last thing I wanted was a hole in my wall. I did, however, require somewhere to store my cookery books and a shelf seemed a good option.)
When selling software projects the important thing for the customer is not what is going be technically delivered, but what that will allow their users to achieve. Understanding and capturing that information is key to providing a flexible yet robust scope of work.
Capturing the outcomes
The format that works for me is to structure a lightweight scoping document to allow a clear focus in the body of the document on the outcomes desired, pushing technical constraints and limitations out to maintain readability. For the outcomes I break these down into three parts
- A high level outcome statement
- A few success criteria
- Any assumptions
Let's look at these in more detail
High level outcomes
I like to present a number of high level outcome statements. Each outcome needs to be carefully considered as we're aiming for as few as we can get away with here. Each also needs to be targeted at a specific role or stakeholder.
Some examples
- Allow an agent to send a message to a list of contacts
- Allow an tradesman to register a device installation
- A manager can approve a draft design from one of their team
- A marketer wants to personalise a message using contact data
- The system owner will be able to see their account usage
I've intentionally mixed the format here as I don't think it's necessary to insist on one structure, and while consistency within any one document is important, insisting on formats like 'As a...I want...so that ' with customers is frankly annoying.
What is important is conveying a desired outcome that has clear value for an identifiable role.
List success criteria for that outcome
Just as when elaborating user stories for ongoing development adding acceptance criteria is essential, Including success criteria in outcome based documentation is key to ensuring that you and the customer are on the same page. The criteria should be statements that provide more explanation in terms of what an acceptable outcome will look like
- It shouldn't be necessary for the user to do any configuration in other products in order to send a message
- The marketer won't be able to send more messages than they have credit for in their account
- The tradesman will be able to complete the process on a mobile device in a potentially dark and dirty work environment
The key here is in identifying criteria that will allow the target users to achieve the outcome they want, in a way that works for them. If the user has to step outside of a natural workflow for them in order to use the software then that isn't a positive outcome - so whether it's being able to use the product on your phone, outdoors in high wind, with dirty plumbers thumbs or through surgeon's gloves - these criteria are the key to ensuring the outcomes are delivered successfully.
List any assumptions to the ability to deliver that outcome
When working with a level of uncertainty we need to make assumptions in order to progress. These could be based on the need for supporting data or capabilities outside of our control, for example
- The 3rd party technology used will provide reporting data on individual message delivery
- The data from the customer training system will provide a suitable ongoing reference list of users in the system.
These assumptions can be invaluable. I've seen project priorities shift massively due to data on the customer side that was assumed by the them to be reliable but was actually unusable. Appreciating that these are assumptions and presenting them as items to be investigated and confirmed as part of the process makes it much easier to discuss the impact should they prove to be false.
Other bits
As well as the outcomes there are other elements that make up a good outcome based scoping document. I find that a structure like this works well:
- Introduction - as well as defining what the project is for its useful to clarify the characteristics of the approach being taken, particularly the acceptance of uncertainty and how this could affect delivery.
- Outcomes - the outcomes as I've detailed above including success criteria and assumptions
- Technical considerations - details around the technical operating environment that need to be considered such as security expectations, target browser levels and devices and hosting.
- Appendices - here I push any detailed items that would impact the clarity of the outcomes, such as data source field listings and reference tables. If it's necessary detail but would make the desired outcomes less clear if included there, it goes in an appendix. I've occasionally also included details in here that need to be completed to provide a clearer scope, such as information on the key fields with which users will be uniquely identified.
What about timescales and planning?
If you are planning to sell a development with an agile approach then some flexibility around delivery is needed. This is a difficult negotiation as the customers much prefer fixed cost and scope projects where the supplier takes on the risks. An effective approach I've used here is to define fixed size delivery 'buckets' or phases. Initially each phase will have assigned essential outcomes, but also some flexible ones that may be delivered, or may be rolled into the next phase. The process outlined at the outset included re-prioritisation in each phase to give the customer control over whether to continue based on the original priorities, or shift to emergent ones.
Will it work for me?
If you're more used to working with fixed specifications you may be doubting at this point whether an outcome based scoping approach would work for you. You'd be surprised. Most organisations are now using agile methods or will at least have some kind of transition project in place, so finding in-house support could be easier than you expect. I've successfully used this approach in some robust purchasing processes in for large development projects in both the UK and US and was pleasantly surprised at the positive reaction.
The fact is that when establishing outcomes what you're creating is a document that places an understanding of their users and their needs as the focus for the entire process, rather than a flashy design or the details of the technical delivery. And if you think about it that way - I think you'd be hard pushed to find customers who wouldn't want that.
References
There are literally hundreds of articles out there on outcomes over outputs - here's one, Google will find you a whole load more.https://hbr.org/2017/02/you-need-to-manage-digital-projects-for-outcomes-not-outputs
Post a Comment