Some things are just bigger than we think they are. Those dizzy spells that you are having that may seem like not that much but turn out to be an inoperable brain tumor like my own mother succumbed to 17 years ago. Sorry about the downer lead off note there... just trying to emphasized that proactive thinking, adequate planning, and making sure you're truly ready for the next steps are very important – sometimes more important than you ever dreamed. You don't always get a mulligan in life – a chance to do over something that you wish you had done differently or planned differently.
That is also very, very true of the projects we manage. Things that seem like minor issues that can be fixed may not be that fixable and may end up shelving or canceling that big project you're working on. A third party database that held the prescription information for my client on my team's pharmacy prescription online refill project didn't seem like that big of a deal. But gaining the ok and cooperation of the database provider to work with us on setting up inputs and outputs to the database ended up being an expensive and time consuming process that was only successful at the 11th hour just before the entire project was going to fall apart. My negotiation skills increased ten fold that day!
So, let's consider a few things that may seem like they just aren't that big of a deal and discuss how they can actually bring down a big project....
Error filled deliverable. We've all heard the expression, “You never get a second chance to make a good first impression.” That holds so true with our project clients. The minute you start sending defective materials to them, that's the moment that their confidence in your ability to deliver quality work starts to drop... fast. If you do it three times like my business analyst did with just a simple PDF file of the Functional Design Document (FDD) on a tech implementation for a major US airline, you realize as the project manager that you better start checking EVERYTHING. A PDF document with bad formatting nearly ended the project. That's the moment I began planning deliverable peer reviews into every project plan and schedule going forward and I never looked back. If you find errors in this document tell me and I'll fire someone – maybe even myself.
Missed requirement. Just one missed requirement, believe it or not, could kill a project. Of course, it depends on how critical the requirement is and when it is noticed. But a major omission like the accounting input / output connection on a new reservation system at a big timeshare resort – like some we have here in Las Vegas that I've worked on tech implementations for (not that I'm saying this did or did not happen to me and my team) – could be devastating if it's discovered during rollout instead of during design. The amount of re-work involved may be hundreds of hours resulting in several hundred thousands of dollars of work that needs to be performed against a budget that is now out of funding. The client isn't likely going to give that away via a change order – although gracious ones who want to see the solution and project succeed – may split it with you. But if no one has the money to proceed and it's a showstopper without it being incorporated, then the project may be dead. Your organization may be also, if there is a lawsuit that follows.
Starting too early. Pressure to start the project before it's ready can be a project killer as well. All planning, all requirements, all risks, all business processes, all assignments, all project tasks, all deliverables, all assumptions... everything related to actually executing on the project... must be accomplished, documented, in place, etc. before starting. You may get pressure from the project customer to get started. You may get pressure from senior management in your organization to show forward progress before it's time to really begin the “real” work. You may even get pressure from your own CEO, but bending to any of that pressure can result in project failure down the road due to insufficient planning or incomplete requirements and no matter who pushed for the earlier start, the fault will still fall on the project manager and team. Ultimately, it really falls on the project manager and if that's you, do you really want that? It can be career ending if the project and failure are big enough. Stand your ground. Insist that the planning happen as planned – call meetings to discuss it if you need to, but don't start before you, the team the customer and the project are truly in the right shape to start.
No kickoff meeting. Never underestimate the importance of a good project kickoff meeting. The purpose of the kickoff meeting is really to ensure that everyone comes out of the gate on the same page and ready to do the right work in the right time and the right sequence to be successful. And to do all of that with the understanding of how things are to be run and performed on the project. Starting before there is understanding of the change process, the methodology to be used, the dates that need to be met and everything else that makes up a project can be devastating if the client is thinking one way and you're planning a different way. Get on the same page and stay on the same page through excellent and continuous communication. And it starts with the kickoff meeting.
Summary / call for input
The bottom line is this... you never know what can end a project. I was running one with the Food and Drug Administration – a big $1.3 million tech implementation – and it had gone on hold for a long period of time. I picked it back up on our side as the new project manager with a new team and the customer team was new as well. The assignment was to get it finished.... we had about half the budget left and half the project to finish. We worked toward the end and too late discovered that we were working off of bad information from the first half of the implementation and it was never going to work – at least not without increasing the budget by about $350,000. I tried to get approval from both sides as did the client side sponsor, but it didn't work and the project died at that $1.3 million dollar budget mark. What a waste. Thankfully, I came through it unscathed both from a reputation standpoint and the customer's perspective, but it could have been much uglier career-wise. Planning, detailed documentation, following processes, kicking everything off properly and maintaining the best communication possible are critical components to successfully completing the project.
Readers – what your thoughts on this list? Do you agree? What would you change about it or add to it from your own experiences? Please share and discuss.