Missing the mark on project deployment
First, let’s consider project success factors. In most people’s books, there are three key success determiners for projects…and ultimately project managers. On budget delivery, on time delivery, and customer satisfaction. And of course that last one is often based heavily on the first two. So, there’s that on time delivery measure. That’s on time delivery of the project as a whole. As we know, there are many, many factors that can play into missing the mark in terms of on time delivery. Several that come to mind are:
- Scope creep
- Error filled deliverables
- Outstanding software bugs
- Loss of key project personnel
- Funding issues
- Unplanned risks arising as real issues
- Problems with a third party vendor
The list could go on and on in terms of what could affect the overall delivery date of the end solution. The key for the project manager is to document the issues and any reasons why the project is delayed and keep it as part of the knowledge base of information for the project – sort of what we used to refer to as the project notebook. When a two-year project comes in two months late it’s nice to have that documentation showing that in month ten of the project work stopped due to customer funding. Any information that documents anomalies to successful delivery of the solution is good to have when it comes time to get final project approval and when you sit down with the customer and project team to conduct a lessons learned session. And be sure to have the schedule affects documented in your online project management software for these same purposes.
Delayed deliverable delivery
Delayed deliverable delivery may seem like a catchy phrase, but it’s painful if you’re a project manager. Some of the same things that affect overall project delivery can affect the timely delivery of deliverables throughout the project. I once had official approval and signoff of a functional design document deliverable delayed because my team kept delivering an error-filled version of the document. First the PDF creation software was altering the format of the document which caused the customer to reject it. Next, once we finally got past the formatting issues, the customer noticed many typos. After I picked myself off the floor and realized that my highly paid technical team was not proofing documents before sending them to the client, I incorporated a ‘peer review everything’ practice on the project and we got past that issue. But we lost valuable time trying to move to the development phase and we lost valuable customer confidence trying to deliver an error-free document.
The bottom line is, the project manager essentially promises the customer that he will be overseeing a successful project for them. One that promises to provide on time deliverables, hold weekly meetings according to a planned schedule, deliver status reports and revised project schedules on a regular basis, and deploy an end solution on the date that was planned in our web-based project management software tool with the customer. Every time you have to apologize and miss one of those dates, you’re taking a hit to your reputation as a project manager, your project is incurring unnecessary expenses, your customer is losing confidence in you, and your company may be suffering as well. Quality control is not just something we need to worry about in our software system, it’s something we need to implement in the overall way we run projects.