I facilitated a pre-sales workshop with a company's customer services team yesterday. The procurement team had issued a request for a Dynamics 365 solution to improve the company's customer service outcomes and mandated a fixed-price initial deployment.
During the workshop it became clear that the customer service team hadn't formulated their requirements yet. We spent the workshop discussing possible solutions to reduce the volume of customer enquiries and complaints rather than using Dynamics 365 to handle enquiries more efficiently. We could revisit the IVR, redesign outbound communications, introduce chat agents and chat bots, enhance the customer portal, intelligently suggest helpful articles, restructure the department, and lots of other good ideas.
The company had run one or two agile projects before, but admitted they were relative newcomers to agile frameworks and had no experience applying all the Scrum practices to a single project. But they really wanted an agile deployment. At the end of the workshop the procurement officer reminded me that the initial deployment had to be fixed price.
Waterfall statements of work
The typical statement of work in a sequential Dynamics 365 project will include a requirements specification and sequence of phases to design, develop, test and deploy a system according to the specification. And if the customer insists on a fixed-price implementation then the consulting partner will perform some extra analysis, add some contingency, and then issue a change request every time the customer says 'um' or an 'ah' during a meeting.
Scrum statements of work
The typical statement of work in a Dynamics 365 project using Scrum will outline a team that will commit to a number of sprints to work on the customer's highest value requirements (which are never be written down in a requirements specification). The project is inherently fixed-price because the resources, their rates and the duration are all known in advance. Agile projects are always fixed-price. How awesome is that!?
What is "fixed-price"?
But when a procurement officer asks you for a fixed-price project, they are not really asking for a fixed-price project. They want a fixed-scope for a fixed-price with no uncertainty about what is going to be delivered, by when and for how much. They want the consulting partner to carry all the risk.
Fixed-scope Dynamics 365 projects are an illusion. Human beings are not capable of knowing exactly what we want from a piece of software before we've seen or used it. We're not capable of writing down our complex needs. We're not capable of intuiting exactly what someone else is imagining. We're not capable of estimating all the tasks required to deliver someone else's dream. It's impossible to specify requirements and madness to bind bad requirements into a contract.
Scrum is a framework we can use to discuss the software you're dreaming of, build some of it and show it to you, get your feedback, and try again. And again. And again. Until before long you've got something close enough to what you wanted that you release it into production. Nine times out of ten, the software you proudly release is not the software you were dreaming about a few months ago. It's even better. Now we get feedback from real users and we try again. And we deploy a new improved release into production. And we go again and again until you don't have any more valuable ideas worth implementing. Celebration dinner. Case study. Industry awards for everyone involved.
I'd love to hear any ideas you have for working with procurement teams and talking them off the ledge of the fixed-scope chasm of doom.
In a future article I'll outline an example of a statement of work for a Dynamics 365 project using Scrum. Until then, it looks like I'll be busy designing Dynamics 365 for customer service with an unknown scope for a fixed price. Wish me luck.