- Business Objectives defined…check.
- Organizational Chart created…check.
- Process Flows defined…check.
- System Context Diagram confirmed…check.
- Requirements written…check.
- Everything handed off to development…check.
So, we’re done…right? Nope, the fun is just getting started!
We spend a lot of time working with our business sponsors, the subject matter experts, and the project manager to elicit and document the requirements. Everyone has reviewed, revised and approved the requirements. We hand off to the development organization, wash our hands, and we’re done. Developers are smart people. They can figure out all of the models we have defined, the requirements we have written. Our blood, sweat and tears will be understood and appreciated, right?
I’m currently on a project where our first sprint worth of requirements has been turned over to the development organization. We had a turn over meeting, told them what documents existed and the location of them all. We even sent an email with links to each item, just to make it easier for them to find all of our deliverables. Imagine our surprise when a few days later we heard from the team leader of development that what we had produced was worthless to them, and they had essentially ignored it all.
The team lead is your typical rogue developer. Rarely did she have decent requirements (if she got them at all), so she had learned to live without them. She got a general idea of what the business wanted, and just built it. It may not have been what the business wanted, but by the time it was built, it was too late to change anything, so the business learned to live with what they got. Not ideal at all. And that was why we were there…to help the business get what they wanted.
What we needed to do was to train the development team what we had produced and how they could use those deliverables. We need to walk through the process flows, and help development understand how they could understand the workflows that the business wanted. We need to discuss how the acceptance criteria could be used to understand the details of how the business expected to be able to use the system.
After a few meetings with the development team, where we went through each of the deliverables and explained what it was and how it could help them, they turned around. All of a sudden, the process flows were the greatest invention! The use stories were considered well written, the data dictionary valuable.
What we were also able to do is understand how we could change a few minor things to make our deliverables to make them even more useful to the development team. Continuous improvement…it is a wonderful thing!
This is something that we all need to do to ensure the success of projects. We need to extend the requirements training to the development organization, and help them understand and consume what it is that we have created. And it is our responsibility to do so, otherwise we fail. Our deliverables are no good if they are not understood. And it is not enough to think that development will understand on their own. After all, how many times do we explain what we are creating to the business? Why would we not spend the same amount of time explaining the same thing to development?
