IT Transformation with SOA

Taming Complexity

The complexity of a project is an intrinsic variable ultimately determined by the business processes. Keeping in mind the key dictum that a technology solution can never be of lesser complexity than the underlying problem it solves, you should first ensure that prior to automation, the business processes are as optimized as possible[1]. Many technology projects end up being unyieldingly complex because they try to tackle what is in essence a mash up of chaotic business rules.

Having said this, there is no reason why the technology solution should be more complicated than necessary. For instance, poor technical decisions or the use of inappropriate software tools can add unnecessary complexity to a project.

Recognizing that a project has an intrinsic complexity framed by the business requirements, your challenge is to efficiently tame this complexity within the realm of the technology and budget available to you. Here we have the “Law of Preservation of Complexity”: N = S + U; where N is the total complexity of the solution (as determined by the complexity of the business problem), S is the technology system complexity, and U is the complexity that the user faces when interacting with the system. Given that the intrinsic complexity of a project is “N”, it is your decision how to apportion the complexity between the system and the user.

Thinking about it, the simpler the user interface, the more complex the technology backend that supports that iteration is bound to be. I’m fairly certain that the underlying software supporting the Apple iPhone is quite complex, given that it is a device universally recognized as providing an extremely-intuitive interface. Alternatively, simple technology implementations tend to deliver solutions that are more manual in nature and hence more complex for the user. A complex solution that delivers an easy-to-use implementation is bound to cost more to develop, but its operational costs, due to reduced support and training costs will be lower. A simple solution that places the burden of complexity on the user can typically be developed more rapidly and at lesser expense, but its operational cost will be higher.

Taken to the extreme, the simplest automation solution is one in which automation ceases to exist and all business processes are manual. The most complex automation solution will probably involve the use of a sophisticated, artificial-intelligence system that is able to take on all automation burdens[2]. This capability, however, has yet to be invented.

In the end, it behooves you as technology leader to ensure that no unneeded technical complexity is introduced into your projects (watch out for that young bright, software maverick who pushes for that “cool”, dynamic rules engine to do the payroll!). Always keep in mind that the single most important independent variable in apportioning complexity is the understanding of the key business priorities and the true capabilities of technology.

The trick is to strike the proper balance in the deliverable. A good technical delivery will endeavor to place the bulk of complexity inside the solution black-box, making the interaction with the software simpler and more user friendly, but not at the cost of creating an un-implementable solution.

Many people confuse complexity with over-automation. If the complexity of the technology solution does not ultimately simplify the interaction with the user then you are not improving things. A personal peeve of mine is the recent “popularity” of so-called voice-response systems. If they were used only for simple voice driven selections, then there would be no problem. The issue arises when these interactive-voice-response (IVR) applications are forced to carry more complex interactions. The fact is that technology is not yet at the point where it can support these interactions in a seamless manner. In the end, the only purpose these “voice-recognition” systems accomplish is to weed out customers’ access to the support staff, at the price of lowered service levels, and also heightened customer dissatisfaction. The manner in which companies use these systems is a typical example of adding complexity for the wrong reason.

Labels: Business Rules, Complexity, Interfaces, IT Transformation Defined, IVR, Project, voice recognition

posted by IT Transformation with SOA @ 11:41 AM

Defining the Project’s Scope and Requirements

The Strategy and Planning for the IT Transformation effort must emanate from the definition of scope and the understanding of the requirements that will be targeted by the initiative. Many compromises must be made in the process, and these compromises become both cause and effect of the ultimate strategic direction.

The compromises deal with the interplay of these parameters for each requirement:

§ Quality: The solidity of the deliverable

§ Cost: The amount of money available for delivery

§ Schedule: The expected delivery timelines

§ Scope: The functionality that is being delivered

These variables are known as QCSS attributes, taken from the initials of each. The business requirements can only reasonably specify three of these factors. The fourth factor will be a result of the project’s dynamics. For example, if the business wants a project done within certain cost restraints, under a specific timeline, and with a specific scope, the quality of the project will be in question.

In this diagram, Functionality is represented by the surface area of the square. The Cost used to meet the Functionality is shown in light grey, and the Schedule (timeline) is in dark grey. Quality is the percentage of the Functionality surface that is being covered by the Cost and Schedule squares. The diagram shows that if the Functionality scope is increased (larger surface), you will either have to increase the Cost, the Schedule, or both to match the new requirements; if not, Quality will suffer.

This “law” applies to all projects and to any combination of attributes. Furthermore, imagine the QCSS variables as knobs on a control panel, each influencing the other[1]. The more money available for a given project, the more potential resources that can be committed; thereby enabling faster delivery and/or more extended functionality. With less funding, chances are the scope will need to be reduced if timelines are to be maintained.

Managing the project budget and the timelines is a straightforward project management function. Project Management disciplines to effectively do this have been developed and can be applied in a systemic way. But truth be said, the most complicated challenge during this stage is to properly manage the amount of requirements you are likely to receive from the business. Let’s face it, this is an IT Transformation project that, most likely, has been sold as the mother-of-all-solutions and that will, no doubt, have the business salivating like a kid in a candy store with all the potential for functions that they have for so many years been deprived of.

However, the fact is that the requirements values tend to follow Pareto’s 80-20 rule. That is, typically 20% of the requirements represent 80% of the solution value, and the other 80% the remaining 20%. Now please don’t go to the business and tell then you will cover 20% of their requirements. Not a good idea. First, the Pareto principle is just that—a principle; not a law. It might be that in your case 40% of your requirements represent 70% of the value. Secondly, that little extra business value that can be attained by covering a few additional requirements might mean the difference between having a highly competitive solution or an also-ran.

What you first need to do is identify the 20% to 40% of the requirements that everyone agrees are a must, and then proceed to carefully analyze and prioritize the remaining requirements in light of their diminishing returns. My own philosophy is to do as much as possible with the money and time allocated (in essence, establish first the cost and schedule surfaces) and then draw a line in terms of what requirements are to be met during that first phase. You can place the unfulfilled requirements in a subsequent phase that might or might not be funded on its merits. If you can do so without eliciting the wrath of the business team, then you have succeeded!

As you can see, managing the overall scope is an activity best handled by the project leader and not to be delegated to line project managers. It requires finesse and political skills in dealing with business customers.

A second dimension that is often left unexamined during the requirements phase is the need to assess the project complexity and define the strategy of how this complexity will be managed. By this, I mean the determination of the strategy balancing the target automation complexity versus the reliance on manual processes. This is the subject of my next blog.

Till then.

Labels: Business Case, Complexity, Functionality, IT, Management, PM, Project, Requirements, Scheuled, Scope, Time

posted by IT Transformation with SOA @ 8:31 AM