Stop project delivery delays for good

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.

  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, 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.

  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 & 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 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!

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.