Stop project delivery delays for good

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:

  1. Distribution of final document
  2. Introduction
  3. Purpose
  4. Scope
  5. Audience
  6. Deliverable information
  7. Document approach
  8. Document structure
  9. 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:

  1. Automated Code Review Results DED
  2. Business and Functional Requirements DED
  3. Business Design DED
  4. Capability Maturity Assessment DED
  5. Completion of all Code Modules DED
  6. Conclusion of Warranty Period DED
  7. Configuration Management Plan DED
  8. Contingency/Recovery Plan DED
  9. Data Migration Mapping Specification DED
  10. Deployment Plan DED
  11. Design and Build of Target State Operating Model DED
  12. Design Specification DED
  13. Future and Current State Assessment DED
  14. Operational Support Plan DED
  15. Operations and Maintenance Manual DED
  16. Organizational Readiness Plan DED
  17. Project Management Plan DED
  18. Project Schedule DED
  19. Release Plan DED
  20. Requirements Validation and Prioritization DED
  21. Security Plan DED
  22. SIT Test Plan DED
  23. System Acceptance Plan DED
  24. System Design Document DED
  25. Technical Design DED
  26. Training Plan DED
  27. Transition and Knowledge Transfer Plan DED
  28. 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!

Previous articleHow to stretch your workday by 20%
Next articleThe missing element when improving team quality of remote teams
Peter is a technology executive with 19 years of experience, dedicated to driving innovation, digital transformation, leadership, and data in business. He helps organizations connect strategy to execution to maximize company performance. He has been recognized for Digital Innovation by CIO 100, MIT Sloan, Computerworld, and the Project Management Institute. As Managing Director at OROCA Innovations, Peter leads the CXO advisory services practice, driving digital strategies. Peter was honored as an MIT Sloan CIO Leadership Award Finalist in 2015 and is a regular contributor to CIO.com on innovation. Peter has led businesses through complex changes, including the adoption of data-first approaches for portfolio management, lean six sigma for operational excellence, departmental transformations, process improvements, maximizing team performance, designing new IT operating models, digitizing platforms, leading large-scale mission-critical technology deployments, product management, agile methodologies, and building high-performance teams. As Chief Information Officer, Peter was responsible for Connecticut’s Health Insurance Exchange’s (HIX) industry-leading digital platform transforming consumerism and retail oriented services for the health insurance industry. Peter championed the Connecticut marketplace digital implementation with a transformational cloud-based SaaS platform and mobile application recognized as a 2014 PMI Project of the Year Award finalist, CIO 100, and awards for best digital services, API, and platform. He also received a lifetime achievement award for leadership and digital transformation, honored as a 2016 Computerworld Premier 100 IT Leader. Peter is the author of Learning Intelligence: Expand Thinking. Absorb Alternative. Unlock Possibilities (2017), which Marshall Goldsmith, author of the New York Times No. 1 bestseller Triggers, calls "a must-read for any leader wanting to compete in the innovation-powered landscape of today." Peter also authored The Power of Blockchain for Healthcare: How Blockchain Will Ignite The Future of Healthcare (2017), the first book to explore the vast opportunities for blockchain to transform the patient experience. Peter has a B.S. in C.I.S from Bentley University and an MBA from Quinnipiac University, where he graduated Summa Cum Laude. He earned his PMP® in 2001 and is a certified Six Sigma Master Black Belt, Masters in Business Relationship Management (MBRM) and Certified Scrum Master. As a Commercial Rated Aviation Pilot and Master Scuba Diver, Peter understands first hand, how to anticipate change and lead boldly.