In most software development work at the office, I exercise a skill, which I can only think of as ‘turn uncertainty into certainty’.
Some months ago, I was one of the ‘architects‘ on a project. The project lead told us that this was an ‘assessment’ project. We were not sure what that required us to do. We asked the powers that be. Their answers did not remove the confusion.
After a bit, this much became clear; we had to discover information that would help the client approve or reject the project. In addition, the project lead also wanted these; a Business Requirements Document (BRD), an Architecture Document, a Test Strategy Document, a Cut-over Strategy Document. What information these documents must contain, always seems vague to me.
Our business domain is vast. The BRD can get pretty detailed. How much detail do you need for a yay or nay decision? The analysts did not know. The project lead’s answers did not help much.
Regardless, we had to deliver something. Our jobs were on the line. My project lead needed something that the client could accept. Her job was on the line. The client needed something that was more than they already knew. Otherwise why engage us at all?
What do you do? I sort of knew what to do. I had been to this rodeo before.
- Give your lead something quick. It must be clear enough to let her immediately know if she can use it. Take the feedback into account, and make another small, quick experiment. Continue that till you arrive at something adequate.
- Accept the burden of research and discovery yourself. Present the information such that the audience only has to say yes, or no. Don’t keep asking, what do you need. Instead, show what you have produced, and ask, does this work for you. Give folks something concrete to react to.
- Keep the frequency of this interaction high. She has to see you digging, and adjusting. That is good for morale, all around. And if you go off on a tangent, both of you have to discover this fast.
- Finally, you have to be ready to make a mistake. Yea, the work takes some courage. If you are lucky, your organization will make it safe to learn by trial and error. If not, well, who told you this was easy?
I know the types of information that characterize software solutions to a business problem.
- Essential business requirement.
- Specification of a solution to that essential business requirement. Broadly, you can often describe the solution in two different ways
- A technology agnostic description
- A technology-centric description
I realized that this conversation related to the technology-centric specification of the solution. So I studied the matter in question till I was able to put together a couple of technology-centric views of the solution.
- A system-centric specification of the business process, in BPMN 2.0
- A UML Component Diagram, which laid out software components that folks readily recognized; this also laid out how the components depended on each other.
As luck would have it, both the project lead and the client found this useful. This became the Architecture document.
I was still not certain that I had enough information for the ‘assessment’. I would wager that at that moment, neither were my project lead nor the client. It did not matter though. They saw that I knew the material that I presented. We went from uncertainty to some certainty. And they decided that if I did it once, I could do it again. That was progress. Onward.