Delivering large scale infrastructure projects successfully
Over the last decade I’ve led or been involved in the review and auditing of numerous large-scale infrastructure projects. A worrying percentage of those projects had run into difficulties, prompting the audit – recovering from which required an expensive and time consuming re-engineering of the project . By large-scale infrastructure projects, I’m thinking of those projects, which span all (or most) Business Units and locations and impact upon multiple business processes. Such infrastructure projects typically include enterprise information security management deployments - in particular Identity and Access Management (a domain where most of this author’s hands-on experience lies), as well as other technology management areas, such as Network and Systems Management and Service Management. Of course it is always better to avoid the problems to begin with, rather than have to go through the process of project review, re-engineering and mitigation. Especially now when trading conditions dictate that every effort is made to deliver on time and under budget it is important that much effort is invested up front to get things right first time round. Four simple guiding principles distinguish the delivery of a successful enterprise project from one that needs eventual rescue:
Make a plan – and stick to it!
There are all sorts of variations on the theme of “Plans are nothing but planning is everything” attributed to Winston Churchill, Dwight D Eisenhower and General George Patten. My personal favourite is “No battle plan survives contact with the enemy”. However, when you’re undertaking an infrastructure project, it’s important to take the time to plan and prioritise properly. This includes engaging with key business stakeholders and building relationships with them. It’s vital that these stakeholders are at least represented, if not actively participating throughout the project.
Remember – the plan needs to stand up to the pressures that will inevitably arise over the time scales involved in enterprise wide infrastructure changes. Beware pressure to modify the plan or the design to accommodate one stakeholder (for example: one software vendor or service provider in a consortium; or an internal stakeholder such as one business unit) at the expense of the overall design. Similarly, over the timescale of a typical infrastructure project, new versions of the core software and hardware products that are being deployed will inevitably be released. You have to have a clear plan of how and when you will adopt these new releases, by allowing for “technology refresh” activities at suitable intervals.
Bottom line: Once the design is signed off, resist the temptation to adopt a new version or service pack, unless there’s a very clear need for some functionality to overcome a major problem.
Listen to the vendor. They know what they’re talking about (most of the time).
At this year’s IAM Summit in London, Gartner Analyst Perry Carpenter pointed out that failing to listen to advice from the vendor and/or systems integrator will in most cases be a mistake. The vendors and their partners have implemented their solution many times. Sometimes, it worked and sometimes it didn’t work so well. It’s worth capitalising on their experience.
This is in fact a double-edged sword, which cuts all the way back to the solution selection phase of the project. Each vendor designs and builds their product to deliver a defined set of use cases in a particular way. During product evaluation ensuring that the actual process needs of the project match the use cases the vendor can perform against is the best way of avoiding the “Sure we can make it do that, but the product wasn’t really architected that way” response later.
Aligned to their product architecture (which mirrors the use cases the vendor has designed for), each vendor will have developed a logical deployment architecture. In fact one major IAM vendor embodies that notion in their “Deployment Playbook”. This is a standard design which embodies all the best practices that that vendor’s professional services consultants have learned over many projects. The vendor estimates risk in terms of deviation from the deployment playbook and costs services accordingly.
Bottom line: Consider the use cases that need to be satisfied during the selection phase and select a vendor that closely aligns with those. During deployment, the closer you can then stay to the chosen vendor’s logical architecture, then the more likely it is that the deployment will be successful.
Beware Showstoppers.
When considering the risks attached to an infrastructure project, it becomes clear that some risks, if they occur, will force the project to be abandoned. The likelihood of running into these risks is exacerbated by the typically long time frame of infrastructure projects. For example, you’re planning a 3 year project built on LAMP (Linux, Apache, MySQL and PHP) and at the same time the Enterprise Architecture Board is planning a strategic switch to ASP/.NET in 12 months time. These risks can’t be addressed within your project, so they have to be treated as assumptions (you assume that they won’t come about) and are “owned” at a higher level in the organisation.
Bottom line: Be sure that the governance arrangements for your project are adequate to ensure that the impact to your project will be considered by the decision makers and also that you have a channel to “escalate” if a project assumption should prove false.
Frequently deliver in small increments and prioritise by value returned.
Implementing a new piece of IT infrastructure, whether for security management, or service management or something else, inevitably takes a long time. It’s a well-know truism that you should plan for the whole of the organisation’s strategic planning horizon (typically 3-5 years) and deliver within the budget cycle (typically 1 year).
Experience has shown however that projects are viewed as being more successful if they deliver value and return on investment in a number of small, regular, and incremental builds. The logic for this is twofold. First, by making regular deliveries into production, the Business can see real value from the project in the shortest possible time. The second reason is more to do with hedging your bets. The completion date for a project is generally derived from the critical path. So, provided nothing goes wrong with any activity on the critical path (which by definition have little to no slack in their “required by” dates) then the project will complete on time.
In reality, the range of possible completion dates for the project as a whole is very wide (with the outside estimate typically 150-200% greater than the shortest duration). Projects which overrun face the risk of being cancelled before completion. By planning to deliver multiple increments, with the greatest business value (and the highest risk) embodied in the earliest increments, then if the project is cancelled early, there is still a working infrastructure, delivering the majority of the benefit to the business. The increments that get cancelled probably contain the “bells and whistles”.
Bottom line: Deliver key use cases first and make regular deliveries of additional functionality, to ensure that the Business can see the value of continuing.
Infrastructure projects can and of course do succeed in delivering value to the Business. But, to achieve this, you need to put a lot of effort into programme management and in particular into publicising you project and its successes to the Business. Above all, keep in mind that just because it’s infrastructure, doesn’t mean that it’s all about IT. Remember that people and processes are involved too.
Tags: Information Security, Strategy