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 |
Partner Enablement and Professional Services Delivery
I have the honor and privilege of leading a unique group of highly talented and motivated individuals. Our group is called the Architecture and Enablement Services team which exists within the Software Sales Practice within the company. The genesis for this group originated in 2004 after Sun bought Waveset Technologies, my previous employer.
At Waveset we had a core professional services team and we partnered with systems integrators to scale our delivery capabilities. This not only allowed us to minimize head count growth as a start-up but enabled us to get traction with large systems integrators despite the fact we were a post bubble start-up company.
After the acquisition of Waveset by Sun in December of 2003, we expected to build out a professional services team internally as well as continue to leverage partners to scale delivery. The Identity Management practice was created to sell Sun's Identity Management portfolio of products include Identity Manager, Access Manager, and Directory Server. We built a team of Software Sales Specialists and Presales Systems Engineers to sell the products. We also created a group that was unique in the industry - a Deployment and Enablement Services Group. We needed to scale the professional services expertise without adding a significant number of new staff. This created an interesting challenge to scale the business and an opportunity to innovate on new business processes.
During FY05, we built an operating model that enabled Sun to scale Identity Management service delivery almost solely through leveraging partner delivery capabilities and without hiring additional internal staff. Instead of tying up our senior technical staff on a single project for months at a time, we built a joint delivery model and quality assurance framework to provide oversight of multiple projects with a single technical resource. We also found that we needed to provide presales deployment services input to during the product sales cycle. Finally, since we were building a partner leveraged delivery model, we needed to provide true deep partner enablement. We built a dedicated team to provide infrastructure and content to our internal delivery staff and to our partner community.
Thankfully, the leadership team allowed us to build out a model that would scale. Though not perfect, this model allowed our team to innovate and develop a strong sales and delivery ecosystem with our partner community while delivering successful identity management solutions to our customers.
Posted at 03:22PM Dec 14, 2006 by Michael Wyatt in Business Leadership |
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 |
Benjamin Wyatt joins the Wyatt Family
Thursday Nov 11th at 1:19pm CST, Benjamin Michael Wyatt joined our clan. Weighing in at 9lbs 7oz, he is already a strapping lad. Mom and new son are both doing very well. Dad is enjoying the time with the family and readjusting to no sleep. Big brother Max is adjusting as good as any 2.5 year old could to sharing the spotlight with a baby brother.
Big thanks to all of my coworkers and industry friends that have asked about Ben's arrival. Oh, yes we DID realize that his initials are BMW.
Here is a picture of Ben:
Posted at 09:04PM Nov 22, 2006 by Michael Wyatt in Personal |
A Personal Project
We are expecting the arrival of my second son tomorrow about 12:30CT (scheduled). I'm taking a few days to get to know my new son and enjoy the family. I'll be blogging again within a few days.
Posted at 03:46PM Nov 15, 2006 by Michael Wyatt in Personal |
Lessons from leading an acquisition effort
I've had the privilege of leading an acquisition effort that started about 1 year ago. The acquisition was completed in on Oct 13th. Since that time I've been the business leader in charge of running the acquired entity in addition to my day job running Sun's Architecture and Enablement services team for the Software Practice.
One of the lessons that is continually reinforced is the need for clear, concise, and consistent communication to various internal and external stakeholders. Much of my time is spent educating and informing internal groups about the objectives of the acquisition and the status on the integration. When you live something like an acquisition effort for a period of months, things are are seemingly obvious to you are definitely not obvious to other stakeholders, many of which will see things through a very different lens than your own.
In order to ensure that the key members of the integration effort including members of the acquired entity leadership team as well as leaders from the acquiring company are all singing from the same song sheet. The amount of investment to initial craft the key messages pales in comparison to the effort to overcome miscommunications.
Posted at 11:42PM Nov 13, 2006 by Michael Wyatt in Business Leadership |
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
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
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...
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 |
