The timeframes on our projects – both projected and real – seem to almost define us as project managers. They define what we are doing today, how successful we are to date, and what our customer likely thinks of our performance. As project managers, it seems that everything we do is measured by time or timeframes. We live and die by them. Our projects fail or succeed by them. Our raises and pay incentives are usually based on them. Our whole careers are one big master project schedule. It almost seems like we should run our lives using a project management software tool – but seriously, don’t try this at home…it won’t go over well.
Missing key deadlines
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 project management software for these same purposes.
Sending off late deliverables
Delivering a deliverable late to the project client can be frustrating and embarrassing…not to mention painful. 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.
Summary
As the project manager, you are essentially promising success to the project client from the start of the engagement. You don’t always keep that promise, but it is always your noble goal and promise to do so. You are promising, basically, 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 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.
