Gettyimages.com/jayk7
Where Project Managers Go Wrong and What To Do About It
Despite training and good intentions, project managers often make the same mistakes over and over again. Here are some things you can do to improve your PM's performance.
My wife and I have lived on an island a 30-mile ferry ride from downtown Seattle for quite a few years…a far cry from our 20 years in the D.C. area. Which is to say there hasn’t been a whole lot of motivation for me to write about government IT projects…a topic that was close to my heart (and wallet) for several decades. A writer by temperament, including many articles for Washington Technology and FCW, I’ve continued to explore the softer side of life in personal perspectives and books. In doing so, I’ve tried to embody a familiar saying, “You can retire from work but you can’t retire from life.” Still, a contrarian by nature, I decided I would explore project management just one last time to shed some light on where project managers (PM) go wrong.
I’m sure most Washington Technology readers are aware that federal as well as state & local government IT projects are too often plagued by cost overruns, schedule delays and technical deficiencies. And though business developers and proposal managers promising the impossible can be one culprit, it has been my experience that a major contributing factor is that government and industry PMs continue to make the same mistakes. And, while formal Program Management Institute training is invaluable, once PMs get thrown into their first project or advance in their careers, most of this knowledge falls by the wayside. Plus some of the fundamentals don’t directly translate to the government arena. What seems to be missing is an institutional sharing of hands-on experience…the “What to Do and What Not to Do” based on previous project successes and failures. So, I’d like to share just a few of these lessons from my latest book, The Essential Guide to Managing a Government Project published by The Government FreeLance Exchange (GovFlex.com).
All IT projects should, but don’t always, start with a solid set of well-written technical and operational requirements that clearly define what the end-user wants. To quote Lily Tomlin, “I've always wanted to be somebody butI see now I should have been more specific.” My standard, after some costly mistakes in the 1970s and 80s, became, “If it can’t be verified by testing or inspection, then it isn’t specific enough.” For instance, “The System shall be user-friendly,” (a real specification requirement from a ‘they-who-shall-not-be-named’ agency), is useless. If PMs accept this kind of ambiguous requirement, they leave themselves open to painful arguments with their government counterparts about project acceptance and financial liability.
You might be surprised how many PMs I’ve coached haven’t actually read their entire contract, including the attachments and special clauses. Talk about a recipe for a disaster! And, asking them about the risk associated with different contract types or for their understanding of standard pricing terminology is a guaranteed eye glaze.
An inability to make sound decisions is often another source of project failure. Too many PMs (and executives) make significant decisions in the hallway without a thorough analysis and discussion with all interested parties. I’ve witnessed $100 million decisions being made this way. Avoid doing it! Instead, adopt a disciplined decision-making approach that identifies success factors and rates alternatives against these factors. Then communicate the decision to all involved. While delaying a decision can be demotivating, costly and unproductive, it can also allow a project team to gather more information and consider better alternatives.
It’s hard to overstate the importance of relationships to the successful management of a project. PMs need to identify the key individuals who are project decision makers or influencers. These people are not always readily apparent. For instance, many IT projects are actually funded by an agency’s operational unit whose buy-in is needed both during the requirements phase and to obtain delivery acceptance. Don’t wait until project acceptance testing to engage with these folks.
Having participated in over a hundred reviews of government projects of all sizes and complexity, I can sadly report that only a handful evidenced a satisfactory degree of risk management, reporting and control. Most PMs and, sadly, their management, didn’t even give risk lip-service! And too few RFPs required it. PMs need to take risk to heart and try to mitigate the major risks on their projects before they occur, so they have fewer major issues to deal with during their projects’ lifecycle.
Unfortunately, until government and industry finds more innovative ways to bridge this PM knowledge gap, some good projects, like fine wines, will inevitably still go bad. I’m hopeful my efforts can put at least a very minor dent in this gloomy forecast!
A (usually) retired writer and blues musician, Mike Lisagor is the founder of Celerity Works and a co-founder of Government FreeLance Exchange. His other books include How to Develop a Winning SBIR Proposal (with Eric Adolphe), How to Win in the Government Market (with Mark Amtower - coming in February), and Personal Growth During the Time of COVID. He can be reached at mike@celerityworks.com.