Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
How Much Proofreading Is Too Much?
| In March I introduced you to Sebastian, a highly competent, upwardly mobile executive who happens to be your boss. A very detailed person, Sebastian works from 6 a.m. to 10 p.m. That post sparked quite a discussion and prompted some ideas for building a relationship with him. Now it's time to put these skills to use! This time around, we're focusing on Sebastian's habit of proofreading. While it's a fact some people can see mistakes in documents that others just miss, his copious corrections are starting to cause issues. Sebastian can and does act strategically. But his habit of correcting everything is causing the project managers and project management office staff in his division to spend an excessive amount of time focusing on the documents' presentation (style, font, grammar, spelling) to the detriment of the more important issues of content and strategy. How do you advise him that his ability to see and correct minor errors might be counterproductive? And what is an acceptable standard for internal project documentation? Post your comments and ideas, and we'll review and consolidate the answers in a few weeks. |
PMBOK® Guide for the Trenches, Part 5: Communication
Categories:
Communications Management
Categories: Communications Management
| Frankly, I have no idea why or how the perfectly working lingo of the old cost/schedule control system criterion (C/SCSC, also known as "the C-Spec") has been superseded by the more recent, trendy jargon, but I am pretty sure project management, as a discipline, would be greatly enhanced if only we could go back to the way it was. When the C/SCSC came out in the United States in the late 1960s to early 1970s, the Department of Defense insisted that organizations with whom they did business had a fairly advanced project management information capability. Because this insistence was attached to large amounts of business, companies took notice and quickly put into place the codified project management practices called for in C-Spec. Coming as it was from the United States Department of Defense, you just knew there would be plenty of acronyms. The time-phased budgets were known as the budgeted cost of work scheduled, which quickly became BCWS and shortened again to just "S." Similarly, earned value was the budgeted cost of work performed, abbreviated to BCWP and then "P." Actual costs, being the actual cost of work performed, then ACWP, had the same last initial as earned value, so it became just "A." Three of the most important concepts in project management information theory had been reduced to single letters. It could even be argued that this entered the realm of code: a code that only the true believers of project management knew by heart. But there was no earthly reason to know what the project managers were talking about if you were a newly minted MBA or an accountant. Their faces would likely assume aspects not unlike those of archeologists trying to understand hieroglyphics pre-Rosetta Stone. Project managers could discuss their cost and schedule performance openly, even the ugly parts, without fear that the non-believers of project management had a clue what was being asserted. Indeed, the folks in accounting took the opposite tack. Their communications lost their original precise definitions and are now mainstream. The "bottom line," originally the last line of information on a profit and loss statement, entered the business lexicon and eventually became synonymous with the final outcome of a process or event. But you know you're in the company of project managers if you overhear a discussion on the merits of the CPI and SPI at the cume level (the reporting of the schedule performance index and the cost performance index at the cumulative, or life-cycle-to-date, level). The Defense Acquisition University actually publishes a "Gold Card," which is, in essence, our secret decoder ring, defining most of the commonly used project management acronyms and formulae. At least we have the "Gold Card." What do y'all think? |
The Courage to Acknowledge
| Last June, I blogged about a presentation on acknowledgment that I gave to 800 project managers at a conference in Helsinki, Finland. Afterward, Agoston Nagy, a participant, shared with me a conversation he had with a senior project executive of an Indian power company. Mr. Nagy's colleague asked the senior project executive what the most important competence of a project manager is. "He answered: 'A project manager must have the courage to acknowledge when somebody does a good job,'" Mr. Nagy recalls. We must consider that this executive was responsible for 16 simultaneous power plant construction projects and many other projects in his company. The team took in accolades: One project won an international award for excellence in 2005, two others were finalists in the same competition in 2006 and another project won in 2008. I really appreciate how Mr. Nagy's example illustrated the need for courage when acknowledging a co-worker. Why courage? Isn't it a simple thing to let someone know how much you appreciate them, how their being part of your team makes you certain you will complete the project successfully? No, it isn't. Acknowledging others in a heartfelt and truthful way makes us feel at least somewhat vulnerable. We are not certain that they will accept the acknowledgment in the right way: What if they think we are trying to manipulate them? What if they think we are not being sincere? That's why we need to be courageous and take the risk -- at all times. It is worth it, no matter how vulnerable it makes us feel! |
What Makes a Good Project Manager?
| I think the mark of a good project manager starts with how they manage projects. In April, the Institute of Taiwanese Project Management gave out its first 10 Outstanding Chinese Project Managers awards. The winners and candidates were examples of what defines a good project manager. In general, most of the project managers who caught the selection board's attention managed efforts that were: • Completed within budget and on time, sticking to their scope and quality • In line with the client company's business objectives or ambitions • A benefit to the economy, society or local community Good project managers also have commitment and determination -- a common characteristic of the 10 award winners. Their background, education and work history all showed they were individuals who, when they committed to doing something, would do all that was possible to get the work completed, even when others wanted to give up. I also realized during the award-selection process that good project managers are a driving force in our society. Their constant, ongoing completion of projects keeps our economy active and competitive. Whether these are large telecom projects (such as the installation of China's countrywide broadband network) or smaller ecology projects (such as reducing the carbon emissions of homes or businesses), the project managers leading these efforts are all doing important work that improves our society and our economy. It is only through their planning, execution and management skills, as well as their commitment and determination, that any project can be completed efficiently and effectively. If you know excellent project managers who deserve to be recognized, consider nominating them in next year's PMI Professional Awards. To all you project managers silently toiling away -- possibly thinking "these awards have nothing to do with me!" -- I would like to praise your work: You are the real driving force in society. Never underestimate how important your contribution is! |
Developing Swift Trust
| My last post posed the question, How do you manage trust with a new team? Some suggested taking a cautious approach to building respect and rapport. Others addressed the long-term nature of trust developed in a traditional framework. These are valid, but there's a different form of trust that can also be highly beneficial to project teams: swift trust. Swift trust occurs when a diverse group of experts are brought together in a temporary organization such as a virtual team created for an urgent project. It's especially prevalent when the team is required to deliver a result that requires interdependent working and there are significant external pressures. The team has to work out their differences on the fly and "blindly" trust one another to do their jobs simply because there is no alternative. In these circumstances, team members tend to exhibit behaviors that presuppose trust. Each person knows they're trustworthy and assumes they can trust the others. Therefore, the team simply acts as if trust is present even though there has been no opportunity to develop the more traditional forms of trust. This is swift trust, and although it can be a powerful force, it is also fragile and easily broken. Activity contributing to the team's common goal, professional behavior and an effective team leader allow swift trust to develop. But it will only last as long as everyone behaves in a trustworthy way. One aspect of developing swift trust is the presence of recognized expertise. We tend to trust modern medicine and therefore tend to trust doctors. Very few people when rushed into hospital in an emergency want to check the credentials and track record of the doctors working to save their life. They trust the hospital to provide competent doctors to help solve their problem. Another aspect is a clearly defined objective and clearly defined roles and responsibilities. The key to developing swift trust is interdependent work focused on a common objective. Each member of the team needs the other's particular expertise for the team as a whole to be successful. Swift trust is not a random occurrence. By understanding the criteria that encourage its development, a manager can create a favorable environment. Then the act of trusting tends to become a self-fulfilling prophecy. By trusting others we encourage both trustworthy behaviors and engender trust in return. However, as with traditional trust, swift trust can easily be destroyed by untrustworthy behavior. It needs nurturing and support. The concept of swift trust is not new. There have been papers and books on the subject for at least a decade. But making pragmatic use of the concept on project teams has not been widespread. If you've been involved in a temporary team under pressure, did you notice swift trust between you and your colleagues, or was it missing altogether? Please share your experiences to help build a better understanding of this interesting phenomenon. |