Mike Wyatt's Weblog
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 |
Critical Priorities
I know that I'm overdue for writing up my take on Time and Materials projects but I been busy with other priorities, especially spending some time with my son Max.
This photo was taken during our brief 4 day vacation to Chicago during the summer. His expression while enjoying two-fisted chicken nugget gourmet dinner on our cruise around Chicago's skyline captures a lot of his personality. We are expecting out second child in about 3 weeks and I'm taking extra time now to spend with Max as I realize that he will be going through almost as much change as mom and dad in the very near future. With the weather in Austin simply perfect this weekend, we had many hours of fun outside.
Thanks for your patience while I enjoy the home front. If you've been burning the candle at both ends with a blow torch, there are few better ways to recharge the batteries than to spend quality time with your family and friends.
Posted at 10:59PM Oct 29, 2006 by Michael Wyatt in Personal |
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
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
Posted at 08:21AM Oct 14, 2006 by Michael Wyatt in Identity Management |
Taxi Cab Confessions of a Broadband Junkie
Though I've grown up with information technology starting with a TRS-80 Model 1 with 4K of RAM and a cassette tape player for persistent storage, I continue to be surprised and amazed at how technology changes our lives. I'm writing this entry from a taxi cab heading from JFK into Manhattan and am fully connected to the net through a Treo 700p (not a 700w!) with a broadband connection. This type of anytime / anywhere connectivity reinforces the continuing blur between work life and personal life. While many pundits are dismayed at the seeming evaporation of down time, I believe that the real issue is the need to take personal responsibility for setting the boundaries between work and non-work time. It is my choice to be connected and writing this entry rather than taking a short nap or just watching the cars go by. I have the option of whether or not to connect and I have the responsibility to chose whether or not being connected at this moment in time is good or bad.
Posted at 09:27PM Oct 10, 2006 by Michael Wyatt in Personal |
Identity Implementations and the Cone of Uncertainty
Two questions that often come up during conversations with customers contemplating initiating an enterprise identity management solution are, "How much will this project cost, and how long will it take?" These is clearly easy questions to ask...it is the answers that are hard! These are even a harder questions when, during the middle of a project, the vendor communicates that the cost of implementation will be materially different than what was originally discussed and agreed upon. Even with good change control processes and governance procedures, what both the vendor and the customer think the project will be in terms of cost, time, and functionality at the beginning of the project and what it actual turns out to be at the end of the project will at times differ by a wide margin. Why is it difficult to accurately size enterprise software implementation engagements? Many factors come into play including but not limited to:
- Customer: lack of knowledge of the vendor's solution's actual capabilities and boundaries
- Customer: lack of understanding the actual business requirements for the end solution - i.e rapidly choosing a solution based on a regulatory mandate without business specific requirements
- Vendor: lack of understanding the customer business requirements for the end solution - over focus on the technical aspects of the implementation
- Vendor and Customer: not investing enough time to accurately capture project requirements - i.e. writing a Statement of Work from an RFP vs. conducting a requirements definition session or workshop
- Customer: Architecture team driving requirements in the absence of end user involvement and buy-in
- Vendor: Overselling the solution where expectations for solution's capabilities are set artificially high - never confuse selling with installing!
With an understanding of the notion of a Cone of Uncertainty, we can begin working on ways to reduce/eliminate/mitigate project uncertainties and move toward more accurate level of effort estimates, better mutual expectations for the project and projects that complete, on-time, on-budget, with agreed upon functional capabilities.
Posted at 02:14PM Oct 09, 2006 by Michael Wyatt in Identity Management |
Into the Blogosphere - Identity Management Leadership
Finally! I'm keeping a commitment to myself and my team to start blogging...specifically about enterprise software deployment with a special focus on Identity Management solutions. Having spent many years deploying enteprise software on the buying side of information technology solutions, I've had the opportunity to see what works and more importantly, what does not work in implementing enterprise software. I want to use this forum to share lessons learned and explore various best practices, critical success factors, as well as land mines that derail deployments. Special thanks to Mark Dixon Mark Dixon's Weblog for his council on getting started with Blogging
Posted at 12:47PM Oct 05, 2006 by Michael Wyatt in Sun |
