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 the 2009 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.
More Here
Courtesy:http://ezinearticles.com/?Managing-Risk-and-Governance-in-Large-Scale-IT-Infrastructure-Programmes&id=3784224