The Tragedy of Government Software Project Documentation class=

The Tragedy of Government Software Project Documentation

I wonder whether project management experts think that good documentation would have prevented Othello from killing Desdemona. Would Othello, in a rage, have consulted the thick binder that attested to Desdemona’s love and fidelity? Shakespeare got to the crux of the tragedy: the informal  communication of Iago.
Yet, documentation scope has become a “best practice” in IT implementations in government. Sign-offs are delayed because the supporting documentation isn’t sufficiently heavy. It seems to me that many observers attribute the lack of documentation, or the precision of documentation, for so many IT and ERP failures in government. This post expands on a the documentation failure pattern described in my posts last year: The Government Project Paradox and Outrageous Fortune of Waterfall Processes in Government. It also introduces a risk-based agile approach to project documentation.

What’s the rationale for detailed project documentation?

There is a long legacy of project documentation for complex software implementations. It’s often considered a solution to the problem frequently encountered in government: enterprise software does not follow required processes. The thinking is that an in-depth articulation of current processes (“as-is”) will ensure that the resulting software meets operational needs. And, in-depth analysis of these processes will identify what needs to change (“fit-gap”) to fully described an improved situation (“to-be’).
This often requires systems integration firms to sit down with government process experts in complex process mapping exercises. These firms will often blame government experts for not fully articulating processes when implementations go awry.

What’s the context for documentation as solution?

My sense is that the ceremony of documentation compliance is more likely to lead to project failure than success. The detailed articulation of “as-is” is about as useful to making systems work as pieces of broken furniture in the “as-is” section at Ikea is for furnishing a home. There’s a reason why systems are to be replaced. So, “to-be” business processes are on the critical path. A more coherent approach is needed.
What happens during the lengthy “as-is” process discovery and documentation?

  1. Change resistance increases because stakeholders and users see no progress, it gives time for the forces against change to sabotage the project
  2. “As-is” drives “to-be” because the first set of documentation becomes the conceptual anchor, especially since change resistance increases
  3. Overly-customized code scope, time, and future upgrade costs that increases because stakeholders demand that the new system behaves much like the old
  4. Reality is rarely documented because government personnel rarely describe workarounds used in current systems, practices that are non-compliant like segregation of duties not respected, or how systems are really used such as using them to record transactions that have already occurred
  5. What’s artificial becomes gospel because of limitations in previous systems leads government experts to conclude that artificial structures like separating budget classifications from accounting classifications, or separating executive and ministerial systems, or odd methods of managing commitments or cash are somehow natural
  6. What’s important is hidden within pages of documentation and traceability among processes, configurations and customizations becomes difficult

Documentation quantity often trumps documentation quality because quantity provides the first visceral proof point that the project team has done something. But, as one of my university professors answered the question of how long the essay should be: “20 pages, but if you have time, make it 12.”

How can project documentation quality improve by reducing documentation quantity?

Project transparency should wait for no one. But, I get the impression that the view is that nothing happened until it was documented. It doesn’t matter whether the tree that fell in the woods made a noise or not. In government enterprise software, the tree only fell down if it was documented. Why should stakeholders wait so long to find out if something happened, or is happening?
A risk-based approach to project management is needed.
That’s where agile processes and techniques are most effective: showing the status of projects almost in real time. Agile processes can use kanban, scrum or scrumban boards to show progress, to dos, priorities, and task assignments. The gap between actual and estimated user stories enables forecasting milestone completion much better than traditional GANTT charts. Project teams do not have to document status as to take pictures of the board. Quantities of uncompleted tasks alert project teams. Problems become visible.
These problems should be documented and stakeholders alerted so that decisions can be made. There’s a reason why business intelligence regimes have focused on exception reporting for major stakeholders. It’s high time to have exception reporting in documentation. And, to have early warning. Stakeholders will understand that the e-mail alert is critical, not just another set of project updated documentation.

How can project documentation differ based on context?

The documentation mentality in government projects is rarely risk-based. There are diminishing returns to documenting everything. Yet, that’s the case with many government contracts where the final sign-off is predicated on full User Acceptance Testing that includes the project documentation. This adds complexity to the testing procedures. We’ve developed a different method that we recommend to any government looking to implement Commercial-Off-The-Shelf (COTS) software, including from FreeBalance:

  1. Anchor the project differently: begin by training the government project staff on the new COTS software showing how government “to-be” objectives can be achieved and how the COTS software meets requirements in different ways than conceived in the previous
  2. Separate configuration from customization: workshop configuration changes with government project staff and end-users with configuration sign-offs when demonstrated while code customization follows agile processes
  3. Risk and value-based customization: identify and document cost-benefit-risks for any customization initiative to improve project decision-making
  4. Agile documentation: leverage and document prototypes and storyboards to get customization sign-off, rather than rely on traditional documentation
  5. Agile testing:  configuration testing throughout the implementation reduces the burden on final acceptance testing that will be more focused on risk: customization, where documentation quality is critically important

How does this agile approach solve the project documentation tragedy?

  1. Change resistance decreases because stakeholders and users see configuration progress and workshops demonstrates willingness to take in user input
  2. “To-be” drives the project because iterations focus on government objectives
  3. Customization contained because the full features COTS software is explored relative to the “to-be” objectives, and customization as exception is fully documented
  4. Reality is embedded because government personnel describe practices during configuration workshops, and vendor experts (this presumes that the provider understand the domain) explain reasons for practice changes
  5. What’s artificial becomes rationalized because the COTS software does not impose these constraints, assuming that the software was effectively designed
  6. What’s important is visible within fewer pages of documentation with effective traceability, and the use of agile boards to provide in-progress reporting