operational readiness and project success

Part 1:

a thought totally unrelated to the normal stuff i blog about has just not been leaving my neural pathways, i began wondering about the effect of the organization on the effectivity (this does not appear to be a word?) of the outcome of an IT project.So often we are quick to pull out the simple anecdotal multidimensional matrices which combine scope, people, process and other simple project attributes, but in 90% of the cases we tend to miss out on one whole dimension of data that is very important to the success of IT projects. Let us call that dimension of data the operational readiness of the organization. This can be broken down to a panacea of different attributes. Where to start?
I suppose let us start at the simplest and easiest to determine, that is in the milieu of the organization. that being infrastructural readiness. This is often only seen as the ability of the customer to deliver the appropriate hardware and environment in time for the deployment of the development test and production environments. Something we never take into consideration is the ability or rather the agility of the organization to be able to adapt to changing requirements due to business or technical constraints and technical incidents. How often does the project not at loose at least 10% or in many cases upto 180% of the time of the project to delays in this simple task? This is geared up for both fixed cost engagements as well as time and material engagements. The difference being the cost is just shifted at the end of the day. The thing that is not taken into consideration is the impact on the human capital on both sides of the equation. The longer the engagement, the longer the extensions of changes to the initial plan the higher the incidence of project fatigue and ip and human capital loss. With project fatigue efficiencies drop on both sides. This is in the domain of the team leaders and project managers to correct these human impacts. In the more advanced methodologies this is where the change specialists step in and moderate the impact of delays on the customer, but what if anything is ever done for the development team. I have digressed slightly, but will faithfully return to the thread of the discussion. Back to operational readiness and efficiency in implementing change. As i mentioned before it is the measure of the agility of an organization that allows it to cope with the inevitable catastrophes and disasters along this road. We more often than not depend to heavily on the inherent ability of the vendor to deliver according to acceptable configuration instructions and management of complexity for the install process to go through simply. Please keep in mind we are talking here about multi-tiered application server and software installs and not your run of the mill single contained application installs, yet even these can give problems.
The question is then how to mitigate and manage this process?

when setting up scopes and technical specifications and processes, is it not better to then make sure that these factors are built into the management of the process and its outcomes and more importantly the ensuing time lines.


But something else that often lacks before this process even kicks off is the vision and drive by the organization to go down the cataclysmic pathway of a development or implementation process(in most cases my reference is towards business intelligence delivery, but this applies just as well to the other forms of technical magic woven by IT guru's sic!). How often when a project is defined the total cost is never totally defined or envisaged upfront.. so often as a project manager or system/technical architect or similar we tend or put in what we call as FAT in he plan and attempt to bolster best laid plans with an acceptable variance. Is this maybe not where we should put he most effort in when a project is designed and planned. Yes in most cases budget and time line and rapid delivery are key outcomes. We must however be totally cognisent that without effective planning at this stage we will fail.

This brings me back to the question of operational readiness and how we determine it. How often as a vendor we recognize a requirement in a customer through the sales and lead process and chase down the deal. In an attempt to deliver and maintain sales forecasts and budget we just don't seem to take into consideration the implementation of the change process within the organization. the vendor and implementation company strives of agility and the ability to deliver through adversity, whereas the customer is not geared up for these levels of change. At the end of the day i suspect this is the challenge for most organizations and vendors supplying services and deliverables. How do we ensure this level of operational readiness? The foremost question that actually comes to mind is to determine the most parsimonious route through this challenge. How is responsibility determined and how are its impacts or the effects of the lack of change managed and mitigated in the life-cycle of the project? Is there a way to manage this change process and its impacts to the organization. If we look at the statistics, albeit that they are deceptive and evil, what is the eventual success rate of most IT based projects. Experience teaches us many of these things, but by the time the experience is paramount how many of these practitioners have suffered massive burnout and no longer have the drive to deliver change and results to a new customer. The best way would be to develop a methodology that is both usable and practical for the implementation, in this case BI, of a project. And there are many existing methodologies and processes that have been defined, but how do we modify and augment them to work in the environment we find ourselves in? Often methodologies or frameworks are only as strong as the team and management both on the side of the vendor and the customer. At best we could wish for some form of partnership between the customer and the vendor. This of course is not possible if the operational readiness of either parties is lacking. So we may have to devise a framework or methodology that can cope with this.