In my lengthy time in IT solution delivery, I consistently see two great confusions that, on many delivery and support teams, impede, prevent and degrade delivery quality.
The two confusions are a result of the inability of many people to conceptualize and abstract solution spaces.
- Process vs. Procedures
I consistently get asked to review or revise process documentation. When I examine the documentation, it rapidly becomes apparent that the documentation spends almost all of its time defining HOW an activity is performed, not WHAT activity is performed. In addition, the documentation does not specify any other essential activity that I would expect to find in a process definition such as Pre and Post-conditions, Inputs and Outputs etc.
Normally, when I point out that the document is really a procedure document, I am greeted with one or a combination of 2 responses:
- The document is a process document, and what am I talking about (Confusion of process with procedure)
- Why write a process document anyway? People just need to be told what to do (I want to cut corners)
I am often given documents that purport to be Requirements Definition documents, only to rapidly find that the document contains references to UI design, report design, operational procedures etc.
None of those artifacts and content items are anything to do with Requirements. They are the implementation of the requirements. When I try to explain this, the most common response I get is “that is what the client wants”. It then becomes apparent that, in most cases, the delivery team are order takers for the client, so if the client says “I want you to create a document that supposedly covers everything we need to know”, they obediently create a jack-of-all-trades-master-of-none document that is not only difficult to read, but also fails to properly elicit Requirements, jumping straight into solution design.
So What Are the Causes?
In both of the above scenarios, there are two underlying drivers for the mindset that led to the creation of mutant many-headed documents that are not what they purport to be.
- Inability to conceptualize and abstract
This is a classic blind spot. Like critical thinking, abstraction and conceptualization are “soft” skills that are often overlooked, in the same way that people management skills are often overlooked when promoting technical contributors to leadership roles. They are not easy to teach, and then it takes time for people to develop and hone them. (DISCLOSURE – I learned on the job as i became a business analyst).
2. Impatience to get to “working code”
I once became involved in a rather spiky dispute with a Project Manager on a new development project. From the very beginning of the project, it was clear that the PM was not a fan of Analysis at all. He was constantly pushing me to end Analysis and move to Design. When I moved to Design, he was pushing me to move to coding. In the process he engaged in some rather juvenile sniping, including quips like “you clearly don’t want to actually do any work on this project”.
The real underlying issue, as I soon realized, was that he saw the only useful deliverable of the project as code that appears to work. Nothing else mattered a damn as far as he was concerned. I never determined whether this was a result of his client stakeholders having the view that code was all that matters, since he never let me spend enough time with the client to form a view. He was definitely a controller.
This viewpoint, I have realized, is very common in a lot of IT delivery contexts. “Screw Analysis and Design, let’s just code” or “they’re paying for code, not documents” are common attitudes, made worse by the move to Agile and DevOps, which appears to many IT teams to eliminate All The Upfront Shit that they hate. Like requirements elicitation, analysis and planning. Many coders hate anything that gets in the way of coding.
The mindset of “let’s just code” may make developers happy, but it ensures that the ceiling on delivery quality is limited, since failure to understand the scope and depth of solution domains is precisely the sort of failure that causes projects to go way beyond budget and timescale, as the terrible truth dawns “shit, this is much more complicated than we thought”.
So What Do We Do?
Training in abstraction and conceptualization is not common, especially in the business analysis domain, which is where Requirements elicitation resides in a lot of sequential development organizations. Business Analysts are often selected on the basis that they are solution SMEs, not necessarily based on actual analysis skills. Process vs. Procedure is a fundamental conceptual lens that ought to be taught also. However, it also falls into the same blind spot as Requirements vs. Design, for the same reasons.
Training in these skills forms part of a process-focussed delivery organization, which values WHAT is done as much as HOW it is done. This is not common, in an era where the first response to cost-cutting demands is often the axing of process and QA teams, on the grounds that the projects can do all of the work. This usually leads to a long slow deterioration in delivery quality, which then requires at least as much time to repair.
Get it right upfront, by valuing processes and the skill of conceptualization, and you will be rewarded in the medium-term. You will also be able to impress the client. Clients tend to respond to IT vendors who have clearly done their analysis homework, as long as it is well-presented.
