A typical engagement for a TrustTech consultant within an Enterprise Information Management (EIM) project would be during the initial phase of solution implementation in the capacity of the Trusted Advisor.
All too often has a well informed intelligent customer been manoeuvred onto a technical path that is fundamentally flawed, the flaws are introduced by allowing an external system integrator to dictate or convince the customer that “All is well“. The reality is that through no direct fault of the system integrator they have directed the project on to a path of an unacceptable outcome.
An important part of the role as the trusted advisor is to ensure that not only are the customer questions accurately answered, but (and during a time of project crises, it is critically important) that the right questions are asked.
The system integrator will often take over a customer function…. and over time erode its quality through replacing business winning high wage earners with less skilled, less motivated and lower paid resources that ultimately reduce the system integrators function to a dysfunctional component of a previously albeit well run, but possibly bloated customer function.
You ask yourself how do they manage it….., well it’s often by self scoring, KPI’s, SLA’s, OLA’s etc, tweaking the numbers until they fit. This is the key difference between how the function used to work and how it now works, the customer no longer has the headache of having to state that this particular function is not working, because it is now a well run function that is clearly doing well because that’s what the BI (Business Intelligence) statistics inform.
When the customer surveys the business to decide which function they prefer, the answer of well it worked better before will be dismissed on the basis of users do not like change. Its a fact most users do not like change, however most users prefer better systems, smarter functions enabling more time to complete their important tasks.
With the definition of better being:
- Less clicks to complete a task.
- Replacing manual tasks with automation.
- Responsive system when attempting previously believed to be complex tasks.
- Best of the web included, for example a Google like search capability.
With all of this in mind, it was within one of TrustTech’s recent customer engagements that a consultant was asked to join a project that was weeks away from a Go Live, with a team of developers that had spent 12 months ( No agile in sight ) developing the bespoke functionality to meet strict customer business requirements.
The task was to produce a high level design for a concise set of complex, interrelated Records Management requirements and as TrustTech consultants have experience of producing RM solutions within the many versions of OpenText’s Content Server, this was a challenge that they met head on. The requirements specified less functionality that was available in Livelink 9.2, this was a technical challenge to effectively switch off capability, something of which Livelink 9.2 wasn’t really designed to be able to do without making large changes to core functionality.
The completed high level design informed the low level design from which, the solution was developed and deployed into a sandbox testing environment, so far so good.
It was at this point that the problems started to arise, whilst the Records Management functionality represented 1% of the total bespoke code, it highlighted the frailties in the process of validating if it was fit for purpose.
The solution in terms of documentation, functionality and robustness on its own stood up well, however, when it was taken in the context of the wider system, it was clear that the solution as a whole was fundamentally flawed from a scalability aspect.
At this stage of the project the system integrator, vendor and customer politics became interesting. The system integrator was subject to commercial penalties dependant on the solution going LIVE, was presenting that “All is well” and from reading the project managers updates indeed “All did seem well“. Upon closer inspection by asking the right questions it was clear that the current solution that had spent 12 months in development was never going to scale or perform.
A couple of risks that had not been considered were firstly, that bespoke functionality could introduce performance and scaling issues and secondly after the solution goes LIVE….. Who is going to support it? Who is ultimately accountable for the solution? Is it the customer, the system integrator or the vendor? (Follow that topic on another day)
The benefit of having a TrustTech consultant who, as an independent resource, able to communicate at senior stake holder level and also technically accomplished became clear, especially at the daily performance meetings when instead on joining in with the blame culture they set about establishing the facts of the issues.
The utilisation of basic, but proven system engineering principles was used to guide the project team through a package of maintenance work in an attempt to recover the project.
Stating the obvious was suddenly ground breaking, so many false truths were embedded within the project, however a fresh look at what was previously a fact exposed inaccuracies. A good example of a false truth was the insistence that the network was never loaded above 60% of capacity, when in fact, overnight backup’s were regularly overrunning into working hours causing the network to be saturated for short but significant period.
Once the consultant had discovered that the basis for decision making was not built on a solid set of facts the decision was made to re-establish the facts and then work on the immediate issues on a customer led priority basis.
This was a very reactionary response to a complex political project environment that required careful negotiation of all the project personalities, the outcome of which is discussed in part two.
Part two next week…..