Mike Wyatt's Weblog

Project Managers - Skillsets Required

I received several comments regarding the need for vendor project managers from yesterdays posting. Unfortunately my comment tracking is not working properly so I cannot respond to the posters. Here are the points made and that I fully agree with and support:

1. Both the vendor project managers and the customer project managers should (*must*) attend at a minimum the introductory technical training on the product or products being implemented. For example, a PM with WebSSO experience may use incorrect assumptions or design biases based on previous experiences and not fully understanding the capabilities and boundaries of the provisioning product being implemented. Having a project manager that simply makes sure the project artifacts are up to date and the billable time and expense are entered may be important for financial management, those contributions have little to do with driving a project to successful completion.

2. Architecture is critical. Frankly I was surprised that readers somehow thought that I put project management at a much higher priority level than architecture. That's not the case at all. That said, the best architecture in the world will be next to impossible to implement without strong project governance including project management. I'll blog more about architecture in a future post. With direct experience with many provisioning and compliance solution rollouts as well as managing a team that has overseen hundreds of deployments, I can state emphatically that when projects fail they fail primarily due to either poor expectation setting during the sales cycle, lack of commitment by the customer to implement the required business process changes, lack of customer staff commitment due to other priorities and poor project governance and management. Yes, I have seen a few projects that have failed or at least struggle due to poor architecture and other that do not have the desired performance characteristics from a transaction throughput perspective but poor architectures are NOT the primary reason projects take years to rollout and don't meet intial expectations.

Finally, this is my first experience of having my content critiqued publically in the blogosphere. Check out James McGovern's response to my previous posting. It isn't surprising that an Enterprise Architect would put architecture as a higher priority critical success factor than project governance. While James is correct that any analyst will provide the feedback on the need for project management / governance, the point James misses is that despite the "common knowledge / common sense" understanding of the importance of project management and governance being importing, in practice it is surprisingly UNCOMMON.

James has a number of other comments related to fine grained entitlements and such. They are good topics to cover and I will be happy to respond in future postings. Feel free to email me directly (I'll update my template soon) at michael.wyatt@sun.com

Posted at 08:36AM Dec 19, 2006 by Michael Wyatt in Identity Management  | 

Project Managers as a Critical Success Factor or Identity Management Projects

My team and I have lived through projects that have run the gamut from extremely successful to unsuccessful. It is interesting that when companies purchase enterprise software and Identity Management solutions in particular, there is incredible focus placed on the ability to meet certain use cases, usually thought up when the Request for Proposal was written. In addition, there is great emphasis placed on "feature function" comparisons between the various finalist product offerings.Though there is usually some attention paid to the implementation approach and the governance model for the project, it is almost always a secondary to the question of product capabilities.

In addition, when a vendor provides an estimate of the level of effort to complete a project, either in terms of hours or dollars, customers do not like the initial proposal. "This is WAY too HIGH! Your competition is 1/2 the amount of your bid." Usually one of the first items to come under attach is the vendor's project manager. I cannot tell you the number of times I've heard the buyer for the customer say, "We have experienced project managers and we will manage our own project."

Unfortunately, in order to "get the deal done" vendors will make this concession. More often than not, when a project gets in trouble, the common issue is not technology (the bits) or even the vendor's technical team. It is usually the lack of strong project management, especially when customers are providing the project manager. Identity Management projects are complex and often political. The systems that an IDM solution touch, especially in the case of provisioning, often cut across functional boundaries, creating an interesting tension within the customer environment. Add to that the need to change to expectations of the customer stake holders regarding the inevitable limitations and nuances of the solution and you get tough situations needing strong project managers.

I'm not saying the customer should not have a project manager on the project; they should but that does not obviate the need for the vendor to also have a strong project manager. Where it works best are when the two project managers hold each other accountable. Without a vendor PM, when issues arise, the vendor's project or implementation team will always take the brunt of the criticism. It is simply human nature; customer project managers will be biased toward their company's point of view. Without a vendor PM, the project can go off track without the vendor having visibility, the implementation team may be tasked with unauthorized change requests, deliverables such as documentation and milestone signoff may lag, the implementation team may get pulled into meetings that negatively impact completion of deliverables, etc.

What about having the vendor's technical lead act as the PM? I've seen this approach fail more often than not. The lead architect needs to have a good relationship with the customer. Often times, if the customer asks if the product can do X, the technical will agree and move toward implementing X even if out of scope. It is not their core competency and I've seen a clear division of labor much more effective (though I've certainly seen consultants and architects that are fantastic project managers too!). At best you have great technical talent time slicing between technical implementation and project management, introducing overhead (and often stress) to the project team.

The best approach is to find the funding to cover the vendor project manager as part of the project and peer them with the customer project manager.

Posted at 07:15AM Dec 18, 2006 by Michael Wyatt in Identity Management  | 

Industry Pundit - Bruce Schneier

Several years ago, someone gave me a copy of Secrets & Lies - Digital Secuirty in a Networked World. I made it mandatory reading for all new hires in the professional services group at Waveset. Bruce Schneier's book is a great foundation on digital security. Though originally published in 2000, almost all of the content is still relevant and accessible to the non CS degreed professional. Bruce is a bright cookie - he has written encryption algorithms including Blowfish and Twofish. Check out Bruce Schneier's Blog. He also has an email newsletter Crypto-gram.

Posted at 10:33AM Dec 15, 2006 by Michael Wyatt in Identity Management  | 

More Enterprise Single Sign On

I received feedback from my last post that Enterprise Single Sign On is actually considered by some to be more straight forward than Identity Provisioning and that I was a bit off base by describing it as complex. Frankly I have not worked with ESSO solutions directly for some time. My principle experience is based on my attempts in the mid 1990s to roll out an IBM DCE Kerberos based solution as well as my experience with other enterprise systems management ESSO solutions during my work implementing Identity Management solutions. Wikipedia has a good explaination for various SSO approaches. One approach that does appear to be successful and far less complex than traditional ESSO solutions is from Passlogix. Though I've not worked with it directly, I have heard from mutual customers that are pleased with their technology and architecture.

Posted at 03:18AM Dec 05, 2006 by Michael Wyatt in Identity Management  | 

Enterprise Single Sign On (ESSO) - the Holy Grail

Though my primary Identity Management experience is with directory services and provisioning solutions, for many, Single Sign On is the ultimate "killer app." The difference between a provisioning solution and ESSO for end users is crystal clear - with the exception of end user password reset, the end user community does not typically interact backend systems like a provisioning solution. Contrastingly, having to log into multiple systems, even with a common credential set is time consuming and error prone

Any corporate user that has to remember multiple credentials (typically user name and password) can appreciate the elegance of the vision of Single Sign On. Login in one time and have access to all of the systems and data needed. There are two primary approaches (and often confused with one another) to SSO:

• Web SSO

• Enterprise SSO

One of the issues with discussion SSO is the CONFUSION between these two types of applications. Web SSO enables single sign on for web based applications, usually utilizing an LDAP directory for Authentication. Integration with Web SSO, while not trivial due to the various web and application server platforms that must be supported, is significantly easier than enterprise SSO. Enterprise Single Sign On has been the ultimate goal for a number of companies for many years. The challenges to successfully implementing an all encompassing ESSO solution are numerous and include but are not limited to:

• significantly different authentication and entitlement mechanisms

• mutually exclusive password policies

• system administrators resistance to implementing a single authentication mechanism

• general platform integration challenges

Given the technical and political hurdles to implementing an all encompassing ESSO solution, many companies are starting with Web SSO and migrating legacy applications to Web 2.0 infrastructure. An alternative approach is to focus on Reduced Sign On where an ESSO solution is implemented for only those systems which most of the end user community utilizes on a regular basis.

The primary word of warning is to a) not confuse Web SSO with Enterprise SSO and to realize the significant undertaking a full blown ESSO solution would entail

Posted at 10:54AM Nov 30, 2006 by Michael Wyatt in Identity Management  | 

Great Expectations

One of the folks on my staff asked that I talk about Expectation Management or the lack thereof in Identity Management deployments. In my entry on the Cone of Uncertainty Uncertainty is typically highest at the beginning of the project. The early coversations during the sales cycle for the solution can have lasting effect - positive or negative - on the customer's expectation for the solution. When I worked at Tivoli, we used to have a saying, "Never confuse Selling with Installing." This is something that customers should keep in mind as well. We all realize that a "perfect fit" solution is as ellusive as the fabled Unicorn. As professionals, we need to present our solutions in the best possible light without creating a situation where the customer feels like they were sold a "bill of goods." Areas of risk of inappropriate expecation setting include:

• Level of Effort to complete the project

• Project Duration

• Customer resources / time commitment required for the project

• End user experience using the end solution

• Skill set of the person or team that will have to support the solution after the production

• Level of effort to create or "tailor" a resource adaptor or connector to connect to a managed system

• Level of effort to change default out of the box capabilities to customer specific use cases

• Price of the professional services to implement the solution

It is far easier to set the right expectations up front than to reset them during the actual implementation project. As software implementation specialists we are obligated to balance the need to get the sale with the need to set appropriate expecations for the project. Here is a brief article on facilitating Expectation Management from a Datamation article.

Posted at 12:42PM Nov 10, 2006 by Michael Wyatt in Identity Management  | 

Just say No to customization!!

One of the biggest issues with enterprise software implementation, including Identity Management, is the desire by the team architecting the solution to "tailor" the implementation to meet every conceivable use case. A new article entitled, "Resist the Urge to Modify draws a great analogy between drinking coffee strait or drinking coffee with cream and sugar. Check it out.

This article points out many of the long term costs of modifications that really are not truly needed.

Message - go for the 80% solution and invest in change management rather than non-standard custom configuration work. It will pay much higher dividens over the long haul.

Posted at 02:08PM Nov 08, 2006 by Michael Wyatt in Identity Management  | 

Burton Group Blog

Normally I delete bulk emails without a second glance but one tonight caugh my eye. Its an email from the Burton Group about their Identity Management and Security Blog

I'm a Burton Group fan. They have both good content (Sun is a subscriber) and balanced analysis. Their Catalyst confererences in the US and EMEA are also key Identity Management focused user & vendor conferences.

Posted at 11:10PM Nov 07, 2006 by Michael Wyatt in Identity Management  | 

Ten Unmyths of Project Estimation

I ran across an article that I like about Project Estimation myths, or as this the author Phillip Armour states, "unmyths ...are truths that, when we look closely at them are not, well, true." The article, Ten Unmyths of Project Estimation covers a variety of topics such as:

• Accurate Estimates

• Project End-Dates

• Estimate vs. Commitment to the Estimate

• Project Estimate is proportional to size of final project

• Historical Data is an accurate indicator of productivity

• More People will get the project done faster (my favorite)

• Defect Free software as an achievable end state

If you need help reseting expectations about project estimations, check out this article. Its a quick read.

Posted at 10:18AM Nov 07, 2006 by Michael Wyatt in Identity Management  | 

Steve McConnell and the Art of Enterprise Project Management

One of my favorite authors on how to do Project Management right is Steve McConnell. Steve has written a variety of books on both software coding practices as well as project management.
Let's be honest - Identity Management implementations are more closely aligned with an application development project than installing an office productivity tool like OpenOffice. Yes, there is an enterprise software solution providing the foundation for the implementation; that said the specifics of the deployment are in various configuration files. In addition, Identity Management solutions, by definition touch other systems such as LDAP, RACF, RDBMS systems etc.
he approach you need to take with implementing an application development effort is analogous to the approach required for an implementation of Identity Management software. What are aspects of an Identity Management solution project?

• Requirements need to be defined / agreed upon

• The solution must be designed

• The solution must be architected

• The solution must be configured / built

• The solution must be validated and tested

• The solution must be promoted into production

• The solution must be managed after implementation

• The project must have change control

• The implementation team must use Source Configuration Management such as CVS

• The project needs a defined governance approach

• etc...

Several of my favorite books from Steve include:

• Software Project Survival Guide - ISBN: 1-57231-621-7

• Code Complete Second Edition - ISBN- 0735619670

Steve has just released a new book that I've just ordered and expect will as good if not better than his previous works: Software Estimation- Demystifying the Black Art - ISBN: 0735605351. In addition, Steve's company,Construx Software has good information on software training and reference resources. Check out this site and look at the CxOne content available as well.

Posted at 10:32AM Nov 06, 2006 by Michael Wyatt in Identity Management  | 

Time and Materials Projects

The most common pricing structure for Identity Management projects, especially large enterprise deployments, is Time and Materials. With Time and Materials projects, there are several approaches, two of which are:

A customer contracts with a service provider for a resource at a specified rate for some duration. There are no specific deliverables associated with the engagement. At Sun we use an artifact called a Consulting Services Agreement or CSA. Usually for short duration general consulting engagements.

A Statement of Work(SOW) is created which includes specific deliverables and pricing for the resources that will perform the work. The SOW usually provides an hourly or daily rate for each resource that will work on the project. The scope of the work performed is typically described in the SOW. Though not included in many SOWs, #Items that are specifically out of scope should be clearly stated as well.

The biggest concern from a customer perspective is that though specific deliverables are listed in the SOW, when the money runs out, there is no obligation to finish the work, or the customer winds up paying for unbudgeted additional hours to complete the deliverables. One way to address this is to have performance criteria in the SOW that protects both the customer and the service provider regarding specific deliverables that must be met in order for the project to be considered complete. Another approach, which I think potentially better is to have a tiered rate structure that at the point the original SOW runs out of hours, future hours are paid but at a lower rate.

One of the biggest risks I've seen in T&M projects is lack of strong project management and project governance. At times the service provider assumes that their job is to work through the project and bill hours. The customer assumes that the deliverables outlined in the SOW are firmly committed. Only when the money is close to gone or gone do the two parties have a hard conversation. By this time, its too late. Even with T&M projects, it is critical that both the customer and the service provider adhere to change control and progress against the plan. Scope creep is often a problem especially if the service provider has resources working at the direction of the customer without a service provider provided project / program manager to buffer the technical resources. I have personally had superstar architects agree to work that is out of scope because they want to solve hard problems and want the customer to be happy with them. When asked to "just let the customer" provide the project management and oversight, I get very nervous. Checks and balances are needed.

Posted at 03:52PM Nov 03, 2006 by Michael Wyatt in Identity Management  | 

Danger: Projects with Not to Exceed Pricing structures

During my time working in the services delivery groups of Software providers, I've seen a fair number of projects that were originally proposed at Time and Materials but were converted during contract negotiations to Not to Exceed.

What is a Not-to-Exceed (NTE) project? NTEs are a mixture of both fixed-fee and time and materials pricing structures. The project is treated as a time and materials project with a cap on expenses. From a customer perspective the best of both worlds - you only pay for the work performed at the negotiated rate but can budget based on the cap. From a service provider perspective, it is the worst case scenario. If you over achieve and finish the project early you earn less money - no upside. If the project takes longer than expected, your revenue is capped but not your expenses or costs to delivery. Obviously customer like this option at face value.

Unfortunately, given the risk of projects that are NTE, service providers concerned at all about the margin will tend to be fanatics about change management / change control which sets up a less than ideal situation for collaboration between the customer and the service provider. In the other case where the project is treated as Time and Materials until the point the money runs out and doesn't have strict change control, there is usually a scramble to just "get done" and both process and quality are thrown out the window. Neither situation is good for the customer OR the service provider.

For either the customer or the service provider, there needs to be clear expecation setting about change control and overall change management should the decision be made to go with an NTE.

Posted at 10:28AM Oct 30, 2006 by Michael Wyatt in Identity Management  | 

Fixed Fee, Time and Materials, and Not To Exceed

When customers engage our company to provide professional services significant time is spent discussing the payment structure for the services. Broadly speaking there are 3 categories:

• Fixed Fee

• Time and Materials

• Not-to-Exceed

In this entry we will look at Fixed Fee. With a fixed fee engagement, there is typically a finite set of deliverables and key project milestones. Billing will be based upon reaching a milestones and obtaining signoff from the customer. This can be a mutually benefitial arrangement for both the service provider and the customer.

First, the customer knows up front the cost of the project, assuming and this is a big assumption, little to no change in project scope. For the service provider fixed fee engagements present a double edged sword. If the vendor is able to complete the project faster or with fewer resources, the margin for the project improves. conversely, if assumptions made during the sizing of the engagement prove not to be true or if sizing estimates are just wrong, this can be a very high risk engagement for the services provider. Early on at Waveset we agreed to do a project fixed fee for $70K. We really wanted to close the deal and didn't perform a good discovery / requirements definition. Had we billed time and materials, it would have been a $350K engagement. Luckily we didn't sign up for too many of those projects as a young software company.

Fixed fee does work well when using a known solution approach, the right skills for implementors, and appropriate customer expectations. When is Fixed Bid bad from a customer perspective? If the customer is only 85% or less sure of the desired end state, Fixed Fee will be frustrating. As the customer learns more about the products in the solution, they almost without exception want to make "small changes" which from the services provider perspective may or may not be small at all. Often, an adversarial relationship develops between the solution provider and the customer. The service provider wants to make the targeted profit margin and mitigate project risk. The customer does not want to be nickel and dimed to death with change control change orders. Even if the project finishes "to spec" the customer often does not have a good feeling about the engagement.

The best remedy for this situation is to have fixed fee engagement tightly and narrowly scoped with plenty of presales discussions regarding the expectations for the project, especially clearly defined items that are OUT of scope. I'll review my take on the other engagement types in future postings.

Posted at 07:57AM Oct 25, 2006 by Michael Wyatt in Identity Management  | 

Custom painting vs. Lithograph

Identity Management projects have been characterized by my college Susan Patterson as custom works of art. Though there are some common elements, many of the implementation are unique works with little repeatability. I mentioned earlier in the Boiling the Ocean entry that one way projects get into trouble is by having too much complexity in a project phase. Often during the sales cycle, when customer ask, "Does your product do X?," our answer is "Yes, it can but that will be a customization."

Just because a given product can do something is a very different question than "Should we do X with your product?" I suggest that it is the vendor's responsibility to educate the customer on best practices and lessons learned from previous deployments. I also suggest that the vendor needs to guide the customer to a solution that may not meet every specified requirement in the RFP, will be deployable, supportable, upgradeable and provide true ROI. "

While every company is different and some amount of tailoring of a solution such as an Identity Management implementation, will be required, the question is a matter of degree. If the customizations are so extensive as to replace core components or the underlying product or fundamentally change the standard troubleshooting processes or upgrade processes, the value of those customizations needs careful scrutiny. "

Over the next 12-18 months, the Identity Management market will need to move to repeatable packaged solution offerings in order to provide the ongoing quality of care customers want and need. Supporting one-off solutions is not good for any of the parties involved. This is a lesson learned by many companies implementing ERP and CRM solutions. The more customization, the more complexity, the more support burden, etc. Ultimately highly customized solutions lower the return on investment of the solution. "

Posted at 07:01AM Oct 19, 2006 by Michael Wyatt in Identity Management  | 

Boiling the Ocean

I've had the honor (or curse) of being involved directly or indirectly involved in well over 300 Identity Management deployments. Many projects have been successful but certainly not all. As referenced earlier there are a number of reasons why projects are not successful, many of which have little to do with the technology involved in the implementation. One of the biggest challenges is when a customer wants to follow the same process for the project that was used to create the universe we live in - the Big Bang approach. What do I mean by the big bang appoach? I'm talking about trying to implement tooo much in a single phase of a deployment. Some of the toughest projects I've seen are ones that involve implementing several different functional solutions as well as connecting to a wide variety of systems during a single project phase. Whether you follow a waterfall, modified waterfall or agilent implementation methdology, the key is to phase the project into bite sized chunks. For example, some of the best projects that I've seen are ones that focus on Phase I getting the Idenitty Management infrastructure in place and providing a "quick win" such as consolidated password reset for 3-4 key systems such as LDAP, AD, and RACF. This approach enables the deployment of the appropriate RDBMS, Application Server, Identity Management software and provides value to a broad stakeholder community with minimal implementation complexity. In contrast I've seen projects that want to provide provisioning, access auditing, and password reset for 15 different types of systems with as many as 1000 hosts in a Phase 1 deployments. In addition to being very expensive and taking a significant amount of time, these types of projects are High Risk. Why High Risk:

• Complexity - building workflows, testing connectivity, and validating data quality on a large numbers of platforms and use cases introduces risks

• Politics - Usually the group implementing the Identity Management solution is not the owner for many of the Line of Business systems that are integrated into the Identity Management solution. Telling an SAP admin that you are interfacing with their system and will be responsible for user adds, deletes, and modifies as well as access control changes is a risky proposition!

• Project Interdependencies - the interaction between various workflows and the managed systems is made overly complex by trying to integrate too many target types or too many hosts in one project phase

• Customer Learning Curve - as the end customer become more familar with the identity management software used for the solution, they will think of interesting enhancement requests for the initial project phase. The simpler and faster phase I is defined, the less chance for significant scope creep

• Project Management - large projects require more oversight, more team interaction and more corner cases to be dealt with. All of these lead to a requirement of more project management overhead or living with more project risk

• Expensive - Big projects take lots of resources and have long durations

I'm sure there are a many other potential risk points that are introduced by using a Big Bang implementation approach. These are simply the ones I've had personal experience with over the last several years. Next time, I'll talk about recommendations that are alternatives to the dreaded Big Bang implementation approach.

Posted at 08:21AM Oct 14, 2006 by Michael Wyatt in Identity Management  |