The need for control – lessons from history part 1

This is the reason we need to focus on the business side and not the tech side of the operation in any transformation or improvement. Everything that is done should reduce or control cost, improve customer service, and provide a competitive advantage. That really means that any business operation should be involved in a type of evolution that leads to an improved ability to compete. No news. But what is important is that to deliver this ability, the business must move to a position of consistently successful change delivery – from the business manager’s perspective. We are not there yet.

To do this we need to learn from our history – the mistakes we made and what we did about them.

In many respects with BPMS supported BPM, we are once again where IT was in about 1980. Nope, that is not even a stretch. For those of us who started our career before 1980, there are a lot of parallels that we can see. I know, I was an analyst back then.

What can we learn from the past?

Although the technology, like CICS and COBOL worked in the 1980s, IT could not consistently deliver applications that really met expectations. Sound familiar?

Today, the newer BPMS tools, Java, rules engines, etc., once again work. They are capable of delivering solutions that we didn’t think possible in the 1980s. But, once again, we have both technical failures and failures to meet business operation expectations. The greatest recent example is the Affordable Care Act Web Site and underlying applications. But these issues are not limited to the government.

In the 1980s we asked what the business wanted, we wrote requirements, we built applications and we delivered those applications into production. But the requirements were not based on a new business operating design. They reflected what someone or a few people thought they wanted – and tried to explain. Also, our metrics were really technical metrics – system response time, screen refresh time, etc.

Focusing only on technical metrics was only looking at about a third of the picture and being separated from the business staff meant we had to infer, interpret and guess at their real needs.

Hindsight being 20/20 for all but those who are totally blind to history showed us that this was a big mistake. We had to stay separated because we insisted on using jargon and we had to focus on IT metrics for union and other reasons. But focusing only on technical metrics was only looking at about a third of the picture and being separated from the business staff meant we had to infer, interpret and guess at their real needs. We did go over the requirements with the business staff and got them approved, but they had little to do with the way anyone envisioned the business to operate and nothing to do with workflow performance management. They simply solved a given narrowly focused need.

This separation is still a problem in many companies with neither side understanding one another or in some cases, trusting one another.

Given time, the solutions improved until they allowed business to go through an evolution to expand and become part of an international market. We did succeed in that way. And we all learned a lot about what works and what doesn’t. The result is the automated foundation for business today. But building it was not easy and it was expensive.

Most of these systems worked technically, but they were not flexible and change required a lot of guesswork. However, over time the businesses adjusted to them and they became part of the "way things were done". That is why many of the applications today are up to 40 years old with changes having been made to changes – the infamous "spaghetti code".

We did however, make one major mistake in the way we built and maintained applications. We imbedded the documentation on the changes in comments in the code with the written documentation being marginally up to date or in some cases, nonexistent. We learned the need to create good foundation documentation the very hard way – we had to maintain the art form that became the spaghetti code. Taking the time to create good documentation is a lesson some technical staff and companies still resist or ignore today – to their ultimate cost.

Involvement

In the 1980s we moved from sending a technical analyst to get requirements to actually imbedding a business user on the team. This person was supposed to be an expert – a SME. Some were, but others were, frankly, the guy who had nothing to do because they weren’t that capable. Overall, that change actually improved things, but not enough to consistently deliver high quality applications. We found we could really build almost anything. But, that is different for building what is really wanted or expected. That required even more involvement from the business managers and staff.

In reality, business managers will receive from any improvement project in direct proportion to what they are willing to give.

Many of us learned a lot from our experiences. The lesson is that business must drive the improvement or transformation and that limited involvement was just not enough. That is a lesson that is now in need of "relearning" in many companies. I have experienced and spoken to others who have also recently experienced business manager "pushback" claiming their staff "doesn’t have time to be involved in the entire business operation improvement or transformation process". Many now seem to want to return to the limited involvement of a few workshops to gather requirements – with IT then going away until the solution is finished. This is leading again to the delivery of solutions that miss the mark. The applications and overall solutions meet every requirement but still fail in the minds of many business managers. These are "technical successes" but "business failures".

The fact is that many IT focused approaches/project managers need to learn again the fallacy of limited business involvement in the operation’s redesign. In reality, business managers will receive from any improvement project in direct proportion to what they are willing to give. So while the level of business manager and staff involvement in any improvement or transformation will vary by complexity, scope, rules, compliance management, and performance measurement, the level of involvement at each phase of the improvement or transformation should be carefully considered and designed to provide the access to business operation expertise needed to increase the probability of a successful business outcome.

Consistency

In addition to the need for business manager commitment, the 1980s also showed us that consistency in application development or modification required the discipline of formal methodologies. The fact is that some project managers were good and could always find a way to succeed. Others did not share that ability. So methodology firms were born and success rates improved.

We have now also learned that formal project management training helps. But even certified project managers fail to deliver what many business managers expect. The problem seems to be that knowing how to manage a project is great, but you still need to know what needs to be done to deliver results. The fact is that business operation improvement and transformation are specialty areas of activity and the project managers need to also understand BPM, BPMS, and more – in addition to how projects should be set up and managed.

This understanding of how business operation improvement and transformation should be approached is today’s issue – not how projects should be managed. We really have project management down pat.

But as with any rapidly evolving approach (BPM) and technical environment (BPMS, Mobility Computing, Big Data, Cloud, etc.), we are again at the point of inconsistent results with a demand for increasingly complex solutions. And again, methodologies are beginning to surface. However, most methodologies are either vendor driven and are really designed to help install and use their products or built by consulting firms for their internal use. These vendors and consultants have again discovered the need for consistency and thus formal methodology.

Next time we will look in further detail on how we can reengineer the process, better improving BPMS and returning control over process changes to the end user.