If you ever played a computer game, you know that great games start easy, and incrementally introduce new complexities. As Nolan K. Bushnell coined the phrase to describe the best games: "easy to learn, difficult to master". So what does this have to do with business applications? Surely, the serious ERP, CRM, and other business software is as far removed from games as a semi-truck is removed from a Bugatti Chiron? You'd be surprised how the two relate if you consider the implementation as the game, and the use (and outcome) as the reward.
Why we are convinced it is not a game
First of all - it just isn't fun. That is just a matter of perspective. Some like strategy games, others love a first person shooter, and then there are those that love the simulation games, and so on. So, I am not going to say: "Of course it is fun!" - as personally I don't find any computer game all that entertaining, I know it comes down to the basic elements of learning, and motivation through progress.
That brings us to the second, and possibly the biggest obstacle with regards to the gaming analogy: it isn't easy to learn, and mastery seems unattainable for us "mere mortals". Only the anointed few (the solution architects and principal consultants) can ever master the implementation of such behemoth of complexity.
There is some truth to that statement - in particular if your software is built on older (read: ancient) architecture, and the design stems from the 80's and 90's from the last century (in business applications, that is analogous to opening a library and deliver your books in clay cylinders filled with cuneiform script). If the last two decades have brought us anything, it is simplification - a simplification that has been enabled by more powerful computers, and more recently, the onset of Cloud. Simply said, the cloud commoditises software - all software. What does that mean? It means that all software is on a trajectory to become easier to implement and easier to use.
Strategy and implementations
What is key to every strategy? Execution. And the key to effective execution? Measurement to adjust. Now this is fundamental to every game, from the very simple shoot 'em up like the good ol' Space Invaders - to the more complex and interactive world of World of Warcraft. How do we know we execute well? We tally the score while playing. How do we know if the strategy is sound? We measure our progress towards the desired outcome - and see if the score is predictable along that path. For example, in chess, you keep score on the number of chess pieces captured and lost - but you track along your strategy if this is according to your plan (i.e. you expected to sacrifice a piece, versus an unforeseen action that resulted in an unexpected loss).
But before we measure our progress, it is very important to realise what the actual objective is. And this objective has to be unequivocally clear with all actors and stakeholders in your project. Typically, these outcomes are all defined differently - the project owner wants the functionality on time, and on budget, the implementation partner focuses on the scope line-items and budget, and for each actor there are different interpretations of "functionality" and "scope". The objective of the implementation is the outcome that needs to be achieved - whatever that measurable outcome may be (more customers, saving costs in the supply chain, increasing inventory turnover by x%, etc).
Shared outcomes make allies out of adversaries
By having a shared objective that is outside of the scope of the delivered functionality, the entire project team has the opportunity to collaborate to that desired outcome. The objective of the implementation is achieving that outcome, or to reach a state that both parties agree is satisfactory (i.e. the additional time and resources required to get to the "perfect" state are outweighs the incremental improvement against the current achieved state). The "Statement of Work" no longer is the guiding document - the delivered features are adjusted based on the measurements of incremental progress.
Incremental progress sounds logical - but it is not always easy to measure. As mentioned before, if you sacrifice a pawn in chess, it may not seem like progress. So in implementations, it is important to have small iterations for which you can measure a state or an outcome. This outcome may seem to be counter to the desired outcome, but is essential to achieving the outcomes that drive this particular project. For example, a website that does not "look as cool as the others" may seem a step backwards, but if this website has the ability to convert faster with less effort, it surely is worth the effort towards the desired outcome.
Sounds easy - keeping the incremental steps simple, and slowly "step" to the more advanced levels of business application mastery. Yet, look at any given implementation plan, and you quickly develop a sense of "major leap", instead of the incremental steps. You are not wrong! "Diagnostic" and "Analysis" activities are the equivalent to "looking before leaping".
The temptation for making the leap is great - as we typically report progress against the plan as the key metric. Instead, we should be measuring the progress against where we came from - as that is a fixed point. Measure against what we can achieve today versus yesterday, not against the utopia at the planned end of the journey. This utopia will most likely change during the implementation. By measuring improvements by the steps completed provides a clear picture that steers as well as motivates. Measure against the desired end-state is virtually impossible at the early stages of the delivery, and therefore at this stage omitted in favour of measuring against "delivered features". Once that has set into the projects rhythm of reporting, it usually is not supplanted by the more effective outcome measurements.
Key takeaways
- Agree with all parties part of your implementation what desired improvement looks like, and how it is measured
- Divide your project in very small incremental steps with a defined improvement against the current state (which may be a measurable outcome, or an obstacle that has been removed)
- Use the progress measurements to evaluate against the desired outcome, and adjust the execution plan as often as required to achieve the outcome
- Do not be afraid to adjust the outcome if the resources and time required to achieve them are significantly high that a return on that investment is not feasible
- The entire team in the project has one goal, which is achieving that outcome. Team members are not divided into groups such as "customer", "partner", and "vendor", but are evaluated on resource requirement (cost rate) versus planned progress (what can they achieve for that cost)