Why Done Doesn't Mean Stable & How to Assess Stability
Roger Mitchell
|
When digital transformation projects come to an end, we consider those changes to business processes or systems as being done (for now). However, this does not mean that we're also stable. Let's use a metaphor to see how done and stable are not the same, then we'll take a look at three points to help assess stability.
Imagine we have requirements to build a structure that is at least 4 feet tall using only a deck of playing cards.
And, because our stakeholders love absurd constraints, they're also saying it must stay upright for at least 1 minute.
We'll probably encounter a series of setbacks during the design and build phases, as the cards slip or move at the slightest movement, but we manage to scrape by our height requirement by a few inches.
We're done!
But are we stable?
Not a chance!
Plus, digital transformation projects are actually small pieces of an overall digital strategy, so there's always subsequent projects to take us back to "to do" from "done".
Let's say our stakeholders return and inform us of new expectations:
Due to budget constraints, they actually expect our tower to remain upright for 1 year, as it must support requirements of another project that was cancelled
And, an executive returning from a trip to Malaysia was inspired by the Petronas Towers, thus we need to create a second tower using the remaining playing cards, and connect them with an iconic sky bridge
We love our stakeholders (repeat that five times with your eyes closed).
Here's how you can assess stability as your project moves into the build phase through completion:
Consider tweaks to existing requirements that are delivered within your current project to understand how those changes would be incorporated into the business process or system
Pretend to design and build deferred requirements to understand how those would be incorporated into your business process or system in a subsequent project
Monitor usage and exceptions to see how a business process or system responds to real usage, including whether external factors are evolving
As simple as this sounds, each of those will uncover obvious "smells" that suggest you're not on stable ground, then it's time to start digging to find out why.
TLDR: You can be done and unstable. Assess stability in the latter half of a project by adding or changing requirements, then monitor usage and exceptions.