The transformation game – projects

This is the third part in a series of articles, that are going to look at business transformation from several angles, pointing out, where modelling your business and IT may be able to help – this time we talk about complex transformation projects, the operational unit of transformation programmes.

 
In the previous post we discussed that even a small IT change could have a major impact on the business, therefore, the possible affects should be analysed BEFORE the change is executed. In this part of our series we focus on larger projects, which involve multiple components in the architecture and modify integrations, processes and data flows. By aiming to achieve certain targets, these projects typically last for a longer period of time, involve internal and external people and consume significant resources.

 
The life of such projects usually look something like this:

Throughout their life-cycle, projects may suffer from several issues. I suppose, the following stress factors commonly cause headaches:

• the demand and requirements are misunderstood (or not known);
• complexity is greater than expected;
• dependencies are not always known;
• scope changes;
• people leave;
• communication problems among internal and external parties;
• hand-over to operations occurs with obsolete documentation.

These (and many other) hold true to Agile projects as well, but we will cover those in a separate article so let’s put the specialities of Agile aside for now.

Most of the issues originate from the fact that people deliver projects and therefore projects also bear human attributes: sleepy, lazy, unstructured, straight-forward, energetic, sick, sick of others, not interested, etc. Therefore, in order to tackle them, good people management is essential spiced up with a certain level of professional “guidance” and effective communication. We talked about people previously, so let’s see what sort of guidance helps as opposed to hinders and how communication can be enhanced.

 

Guidance

What I mean by guidance is that certain cornerstones are needed on the route of delivering a solution in response to a particular demand. This is a long journey and some of its sections might benefit from strict processes (eg. procurement) while others might need more freedom (eg. development) to achieve the best performance – compliance – creativity mix. Still, they need to deliver one set of goals together and for that it is necessary to determine certain guide-posts.  These will provide direction for the work within the segments and help in coordinating them.

It is like the Red Bull Air Race, where you have one track with multiple air-filled pylons that the pilots need to navigate. If you miss one, you’re out. If you touch one, you’re out. If you don’t keep the principles, you get a time penalty. However, between the pylon checkpoints you have some freedom to fly the way you find most effective.

For projects and for the entire solution delivery chain the following are strongly advisable:

• standard deliverables that make sure that all the required information is available for decision making in order to advance to the next phase;
• principles and standards, such as enterprise technology standards or security guidelines, which provide professional boundaries and support for new solution development projects.

 

Standard deliverables are standard in terms of the structure of the content and compulsory in nature. For instance, the company can agree on a directive on two possible “emergency exits” so that demand owners can decide a Go / No-Go for a project:

• The first option would be after the demand analysis resulting an Initial Demand Plan, which assesses the benefits, the required changes and costs of the project. It is done at a very high level, but it looks at the demands from the same perspective and is delivered quickly (within 2 weeks). We can generally say that a +50 / -50% cost assessment error is acceptable for a quick Go / No-Go decision. Go means that a more detailed Logical Architecture Plan is made, No-Go, that the demand is dropped.
• Upon a Go decision above, the logical architecture planning exercise does a more in-depth analysis of the requirements and comes up with a much clearer logical model of the solution. It produces a Plan, which describes what needs to be done, what is changing, what integrations and data flows are necessary, who are impacted, which existing components can be reused, where in the processes the new solution will be used and by whom – and eventually what are the predicted costs of the whole endeavour. It is done over a period of 1-2 months and in such an instance we can accept a +10 / -10% costing error. This is the second (and last) option, when the demand owner or the management can decide to drop the demand, at a relatively low initial cost.

These guide-posts provide the right information to the decision makers in the same format, addressing the demands according to the same criteria. It can (and should) be made compulsory that the given project cannot receive budget and proceed if this information is not present and available.

 

Many people treat principles and standards as recipes to success, which are definitely not in it of itself. If understood well, they should help you to decide but they are not the decisions themselves. For example, to satisfy a business demand you might want to push to use what the company regards as “preferred technologies”. However, it might not always be possible due to having to adhere to project deadlines dictated by market drivers. Therefore – if other considerations such as security are met – it might be possible to deliver the solution on time by employing the use of other technologies. At the same time, a plan for meeting the compliance requirements in the future should also be considered.

 

Communication

If there is one key factor to successful transformation initiatives, then effective communication is that. Telling the truth is necessary everywhere:

• How do you write demands: do you want people to understand it? Do you want to demonstrate to the decision makers that you have thought of everything?
• Is the commonly understood language used: if I say “CRM system” or “Order handling process”, does everyone within the organization think of the same thing?
• How does IT demonstrate the amount of resources needed to business decision makers?
• How does business make itself understood with the IT when writing user stories;
• Are the accessibility of corporate standards met? Are the types of currently “preferred” technologies clear to everyone involved, who are going to implement the new solution?
• How easy is it to follow and adhere to them? Are the information security guidelines just rigid compliance checklists, or are they broken down into easy-to-follow solution development strategies?
• How does IT Development hand over the solution (providing information about it) to the IT Operations?

 

The language, tone, timeliness and relevance of the content define its quality. Throughout the project, people need to make decisions based on the available input, therefore these qualities have special importance. The clearer the input, the better the results that can be expected from the processing party. The lack of professional background and proper understanding can hinder the information exchange, therefore both parties involved have to find ways to bridge the gaps. One way of doing that is to have an agreed set of commonly understood components. Another method that I have found particularly powerful is the use of visual representations of complex issues based on these commonly understood components. Both should reduce the time to understand the issues and to increase the likeliness of avoiding unnecessary loops in communication. And eventually, the poor allocation of resources, which of course leads to the unnecessary burning of dollars.

Guide-posts are also a means to enhance communication between the phases and participants of the projects, along with external entities, such as regulators, partners, and so forth. For instance, a Logical Architecture Plan can be used as a checklist for procurement to search for solutions and for available solution providers on the market, who can meet the requirements. A version of the solution can be used in the technical content of tenders, which communicate to the potential solution providers the aims of the new requirement and how it should fit into the relevant slice of the overall architecture landscape. Thus, they are more likely to receive tender responses that match the needs from solution providers, who can assess the risks of implementation better – making as realistic an allocation of man-day reserves as possible.

 
To sum it up, the performance of projects depend on people and the quality of their decisions. In the absence of commonly agreed to principles and communication vehicles they will probably need to go through multiple loops.  Can you afford the risks and costs associated with those?

---

 
About the author