Have you been on a project where the dates slipped? Maybe you’re using agile and, despite the team’s best 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 it up to be efficient or incentivize partners correctly. A lot of times, it’s not the team’s fault that things don’t go as planned. It’s also not the fault of the vendor. It’s usually that the contract structure doesn’t support efficient delivery, and it may include backwards incentives.
One of the most powerful concepts I’ve discovered throughout my entire career is called a delivery expectation document (DED). It sounds like a simple concept, but guess what. Almost no one uses them. Why? you ask. Because they hold everyone—especially vendors—accountable.
The purpose of a DED is to absolutely and explicitly clarify delivery expectations. It removes all doubt about what the vendor is expected to produce and how to perform. The document also specifies the format and style of what’s expected in each artifact or deliverable.
The DED is attached to the end of a contract. This attachment is essential as the final addition to the contract, and it’s part of the signed and executed official contract. There are no gentlemen’s agreements conducted after the contract is signed. DEDs are part of the formal contract.
The underlying value of a DED is that it shifts the contract focus from time and materials to linking payments to delivery.
Have you ever had a vendor tell you they won’t be able to hit a release or business go-live date? I think we’ve all 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, but the vendor eats the cost of that delay with the DED model. Vendors are incentivized to perform to the contract—because it links payment to delivery. When there’s a miss, it’s bad for everyone. This creates a shared goal for both client and contractors. This helps unify the team.
In most contracts, the payment schedule states something like there will be a monthly calendar, and 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 aren’t 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. This announcement was anchored with a lot of excuses (and no reasons). Of course, this was sensitive, and I immediately started looking 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 weeks of billing for the 12 consultants engaged on that project.
Using some quick math—our 12 consultants were paid $250/hour ($3000/hour total) and multiplying that by 80 hours—I discovered that those two weeks cost us $240,000. Not only did we incur a two-week delay, which our business partners didn’t take well, we also needed to communicate that we were forecasted to now overspend $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 based on two primary factors. First is growth—how many new contracts dollars (net new) they sign every quarter. The second is the calculated margin 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 maintained very high margins on those two weeks of additional and unplanned work. Eventually, this work would have to be rolled into a new contract—because we’d 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 contract delivery. I’ll share a couple of examples.
Let’s say the deliverable is a project plan. I’ve seen partners provide a simple PowerPoint document comprised of a single slide with a couple of milestones and chevrons representing generic dates claiming the project plan was delivered. Technically, this is a project plan, and, as a client, we need to continue to make payments.
We all know this 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, what comes to mind is an integrated project plan that captures the initiative’s end-to-end work. The plan includes the requirements to get the initiative over the line, and it concludes with a 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 with 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’s a sample DED outline to provide a framework to define intent:
- Distribution of final document
- Introduction
- Purpose
- Scope
- Audience
- Deliverable information
- Document approach
- Document structure
- Document acceptance criteria
The DED identifies the intent, purpose, audience, format, structure, 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 addressed by a DED.
When a DED model is implemented, I’ve found there are immediate 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 and 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 1 date we require, they’re fully incentivized to ensure they deliver on time.
Now, sometimes, situational or environmental factors prevent delivery. This could be a delay in the business leader’s availability or a 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!