Archive

Archive for the ‘Leadership’ Category

Advice to CIOs for High Exposure Projects

September 14, 2009 Leave a comment

I read an article in CIO Magazine about the plight of today’s CIOs when multi-million dollar multi-year projects go awry. The article entitled “The CIO Scapegoat” indicates that it is unfair to hold the IT department completely responsible when there are so many other business units that contribute to a project’s demise. In many cases, the CIO takes the fall for the failure and, as a direct result, they are either demoted, moved into a different organization or let go altogether.

The article goes on to provide advice to CIOs who are beginning such undertakings. First and foremost, large, complex projects should be broken up into “bite-sized” chunks and proper expectations of what will be delivered in each “mini-project” should be set – and agreed upon – with the various stakeholders.

I could not agree more with this statement and find it most concerning that this is not more of a common practice within the IT industry. In our World of rapid prototyping (turned production) and just-in-time development, to think that you could perform a multi-year project without implementing several checkpoints along the way is simply insane. This may be one of the reasons why the average life-span of a CIO is only two years within the same company.

CIOs who agree to perform projects under such conditions really need to read my previous blog entitled “Lessons Learned from Enterprise Identity Management Projects“. While it was written mainly for enterprise identity projects it has direct applicability to any enterprise project. In that article I directly address specific points about expectation setting and bite-sized chunks (did CIO Magazine read my blog on this?) and by taking my advice to heart, the average CIO might be able to extend their stay.

Lessons Learned from Enterprise Identity Management Projects

August 1, 2008 Leave a comment

I have been implementing and/or managing identity-related projects for over 10 years now and I can say, from experience, that the biggest problem with any Identity Management project can be summed up in one word: EXPECTATIONS.

It does not matter whether you are tackling an identity project for compliance, security or cost-reduction reasons. You need to have proper expectations of what can be realistically accomplished within a reasonable timeframe and those expectations need to be shared among all team members and stakeholders.

Projects that fail to achieve a customer’s expectations do so because those expectations were either not validated or were not shared between all parties involved. When expectations are set (typically in a statement of work), communicated (periodic reports), and then reset if necessary (change orders), then the customer is much happier with the project results.

Here are a few lessons I have learned over the years. While they have general applicability to major projects, in general, they are especially true of identity-related projects.

1) Projects MUST be implemented in bite-sized chunks.

Identity projects are enterprise-wide projects; you should create an project roadmap that consists of multiple “mini” projects that can demonstrate an immediate ROI. The joke is, “How do you eat an elephant? One bite at a time.” To achieve success with identity projects, you should implement them one bite at a time and have demonstrable/measurable success after each bite.

2) The devil is in the data.

Using development/test data that is not representative of production data will kill you in the end and cause undue rework when going into production. Use data that is as close to production as possible.

3) Start with an analysis phase BEFORE scoping the entire project.

I HIGHLY recommend that the first project you undertake is an analysis. That will define the scope for which you can then get a better idea of how to divvy up the project into multiple bite-size chunks and then determine how much — and how long — each chunk will take. This allows you to effectively budget both time and money for the project(s).

Note: If a vendor gives you a price for an identity implementation without this, then run the other way. They are trying to simply get their foot in the door without first understanding your environment. If they say that the analysis phase is part of the project pricing, then get ready for an extensive barrage of change orders to the project.

4) Get everyone involved.

Keep in mind that these are enterprise-wide projects that affect multiple business units within your company. The project team should contain representatives from each organization that is being “touched” by the solution. This includes HR, IT, Help Desk, Training and above all, upper-level management (C-level).

(The following items apply if you are using external resources for project implementation.)

5) Find someone who has “been there and done that”.

Ask for references and follow up on them. More and more companies say that they can implement identity-related projects just because they have taken the latest course from the vendor. This is not enough. If training alone could give you the skills to implement the product, then you would have done the project yourself. You need to find someone who knows where the pitfalls are before you hit them.

6) Let the experts lead.

Don’t try to manage an Identity Management project unless you have done so before – and more than once. I have been involved with customers who have great project managers that have no experience with identity projects, yet they want to take ownership of the project and manage the resources. This is a recipe for disaster. Let the people who have done the implementation lead the project and allow your project manager to gain the knowledge for future phases.

7) Help build the car, don’t just take the keys.

Training takes place before, after and during the project. Don’t expect to simply take “the keys” from the vendor once the project has been completed. You need to have resources actively involved throughout the project in order to take ownership. Otherwise you not be able to support the product — or make changes to it — without assistance from the vendor. Ensure that you have your own team members actively engaged in the project – side by side with the external team. To do this, you have to ensure that they are not distracted by other work-related tasks.