Have you been on a project where the dates have slipped? Maybe you’re using agile, and despite the best team’s efforts, dates consistently drift away from you. I plan to offer some insights today on that exact topic and how to remedy these situations.
Hi, I’m Peter Nichol, Data Science CIO.
One of the challenges with delivery is that we don’t set up delivery to be efficient or incentivize partners correctly. A lot of times, it’s not the team’s fault things are going to plan. It’s also not the fault of the vendor. It’s usually the contract structure that doesn’t support efficient delivery and includes backward incentives.
One of the most powerful concepts that I’ve discovered throughout my entire career is called DEDs or delivery expectation documents. It sounds like a simple concept. Guess what? Almost no one used them. Why, you ask? It holds everyone, especially vendors, accountable.
The purpose of a DED is to absolutely and explicitly clarity delivery expectations. It removes all doubt about what the vendor is expected to product and how to perform. The document also specifics the format and the style of what’s expected in each artifact or deliverable.
The DED is attached to the end of a contract. This attachment is essential, the final addition to the contract, and is part of the signed and executed official contract. They are not gentleman’s agreements conducted after the contract is signed. DEDs are part of the formal contract.
The underlying value of a DED is that they shift the contract from time and materials to a contract that links payments to delivery.
Have you ever had a vendor tell you they’re not going to be able to hit a release or business go-live date? I think we’ve all have been in that uncomfortable position more than once. The issue is that the vendor makes more money when delays occur. When using DEDs, we all feel that same uncomfortable feeling of not hitting our target. The vendor also eats the cost of that delay with the DED model. They are incentivized to perform to the contract, a contract that links payment to delivery. When there is a miss, it’s bad for everyone. This creates a shared goal for both client and contractors. This fact helps unify the team.
DEDs tie payments to delivery. Usually, the payment schedule says something like, “Hey, we’re going to have a monthly calendar where on March 1, April 1, and May 1, payments will be made.” The problem with this model is that payments are made and contractually required regardless of delivery. We are not tying payments to delivery with this old paradigm.
I recently learned that a critical project for a May 1 go-live was negatively impacted by two weeks. With less than two weeks before go-live, the vendor informed us that the delivery would be delayed two weeks anchored with a lot of excuses (and no reasons). Of course, this was sensitive, and I immediately started to look into the root cause and who was at the heart of this delay. What I discovered was that our vendor partners weren’t impacted at all. They all got paid on time. Shockingly, because the delivery was extended two weeks, they actually made an additional two-week of billing for the twelve consultants engaged on that project.
Using some quick math and taking our 12 consultants at $250/hour ($3000/hour total) and multiplying 80 hours, I found out that two-week also cost me $240,000. Not only did we incur a two-weeks, which our business partners didn’t take well, we also needed to communicate that we were forecasted to now overspent $240,000 on our budget for the initiative. Needless to say this information wasn’t well received.
As you may know, managing consultants are paid their salaries primarily by two primary factors. First is growth or how many new contracts dollars (net new) they sign every quarter. The second is what the calculated margin is on those signed contracts. In our situation the managing consultant just increased their total net sales for the quarter. Also, given that the margins of the old contract were inflated, the vendor also maintained very high margins on those two-weeks of additional and unplanned work. Eventually, this work will have to be contracted into a new contract, as ultimately, we’ll overspend our existing contract.
If you’re not linking payments to delivery, you’re not incentivizing your strategic vendor partners to be good business partners.
The idea behind a DED is to formalize deliverable expectations and clarify the intent of the artifacts provided as part of contact delivery. I’ll share a couple of examples.
Let’s say the deliverable is a project plan. Well, I’ve seen different partners provide a simple PowerPoint document comprised of a single slide with a couple of milestones and chevron’s representing generic dates, tossed in between a month. Technically this is a project plan, and as a client, we’ll need to continue to make payments.
We all know that level of detail doesn’t constitute a useable or reusable project plan. It’s not actionable. It’s not sufficiently detailed. By using a DED to define the project plan’s intent and what you expect as part of that delivery, you clarify expectations for all parties involved. You also don’t have to pay if that artifact isn’t useable.
When I think of a project plan, an integrated project plan that captures the initiative’s end-to-end work comes to mind. The plan includes the requirements to get the initiative over the line and it concludes with warranty. It also includes follow-up items required as part of the warranty and the post-implementation phase. It answers questions such as:
- Who did you talk to build this plan?
- What departments added to the development of the plan?
- Who contributed which sections to the plan?
- Was the plan made in isolation by the vendor, or was it a collaborative work product?
When you elaborate through the DED sections, you begin to understand how a DED is outlined to ensure that the full intent of the document is being captured. Here is a sample DED outline to provide a framework to define intent.
- Distribution of final document
- Deliverable information
- Document approach
- Document structure
- Document acceptance criteria
The DED identifies the intent, purpose, audience, format, structure, the approval cycle, and how exceptions will be handled for that artifact. How are we going to deal with changes? Who’s going to sign off on this artifact? These questions all get address by a DED.
When a DED model is implemented, I have found, there are immediate being changes in the vendor partner performance. Why? Now incentives are aligned to performance.
Here are some examples of DEDs I’ve developed over the years.
- Automated Code Review Results DED
- Business and Functional Requirements DED
- Business Design DED
- Capability Maturity Assessment DED
- Completion of all Code Modules DED
- Conclusion of Warranty Period DED
- Configuration Management Plan DED
- Contingency/Recovery Plan DED
- Data Migration Mapping Specification DED
- Deployment Plan DED
- Design and Build of Target State Operating Model DED
- Design Specification DED
- Future & Current State Assessment DED
- Operational Support Plan DED
- Operations and Maintenance Manual DED
- Organizational Readiness Plan DED
- Project Management Plan DED
- Project Schedule DED
- Release Plan DED
- Requirements Validation and Prioritization DED
- Security Plan DED
- SIT Test Plan DED
- System Acceptance Plan DED
- System Design Document DED
- Technical Design DED
- Training Plan DED
- Transition and Knowledge Transfer Plan DED
- Wireframes DED
Instead of having that delay and trying to convince the vendor to find a way to deliver on the May 1st date we require, they are fully incentivized to ensure they deliver on time.
Now, sometimes, the situational, environmental factors prevent delivery. This could be a delay in the business leader’s availability or delay in receiving a critical product, or a supplier delay. Things happen in life and in business and it’s important to be reasonable. In these cases, you work together as partners and figure it out. However, for most situations, you want that vendor partner incentivized to deliver on time or even early.
When you tie payments to delivery, by leveraging the DED model, things start to happen. Do you wonder why you have project delays and then more delays? Are you curious why agile really isn’t making the waves you anticipated and why you consistently have to push out timelines? You might want to consider implementing a deliverable expectation document (DED) approach in your contract lifecycle.
If you’re interested in a sample DED, send me an instant message on LinkedIn; I’d be happy to share an example with you.
Hi, I’m Peter Nichol, Data Science CIO. Have a great week!