Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Treat Me as a Client
Categories:
Teams
Categories: Teams
| Dealing with vendors and customers provides a very good example of the peculiarities of human behavior. As a project manager, you may feel obliged whenever you do anything for your customer. But when it comes to vendors you perhaps put yourself in a position above them and treat them differently. Take this example: In the IT industry we have a software engineering process group (SEPG) and software quality assurance group (SQAG) responsible for ensuring the implementation of Capability Maturity Model Integration (CMMI) processes. Project teams follow the groups' instructions and do whatever is required to clear an audit. Once the organization clears the audit and receives a certification, no one cares about the processes anymore because of the following reasons: 1. The project team feels unnecessary extra work was pushed on them by the SEPG/SQAG groups and the project team just wanted to be done with it. 2. The project team feels that they are doing a favor to SEPG/SQAG by implementing the processes rolled out by them, and the SEPG/SQAG feels otherwise. The best way to keep a sustainable process model is to mentor project teams about the importance of processes to their project. This compare to what we do with our client -- we work as a trusted advisor, providing consultation at each step. When it comes to an internal project we start treating internal teams as a vendor and ask them to do whatever we need, it doesn't matter if it really adds any value to them. My suggestion SQAG/SEPG teams is that you shall treat the project teams as your client and act as a trusted advisor to them. This is the only way you can have a sustainable model. |
Changing Taiwan's Project Management Outlook
Categories:
Leadership
Categories: Leadership
| This is a guest post from Roger Chou,
PgMP, of the Institute of Taiwan Project Management Five years ago in Taiwan, there was a general lack of awareness about project management. This led all of us in the project management community to some basic questions: How could we prove the value of professional project management teaching and qualifications to the country's leading opinion-makers? And how could we show that having as many qualified managers as possible would be good for business and therefore for society? We decided to provide free project management training to business leaders, company managers, politicians and other influential people. All of these people knew enough about management skills and practices to take such an invitation seriously--and if it was free, how could they refuse? In this way they would understand what all the Project Management Professional (PMP)® education providers were trying to achieve. This became our strategy: influence the influential. After getting first-hand experience of what it meant to be trained and to work as a professional project manager, participants started to endorse project management education and qualifications. At the same time, we also facilitated numerous newspaper reports on major successful projects, including Taipei's Tower 101. We also managed to get over 2,000 people--many of whom participated in the free training--to sign the petition for proper project management training sent to our main forum of elected politicians, the Legislative Yuan. Following this petition, we wrote an open letter to Taiwan's president about the importance of project management teaching and qualification. One of the hardest places to introduce new ideas, practices, technology or anything that requires rethinking convention is within government departments. They see their main responsibility as implementing policy--discussions about or changes to working practices could be potentially costly distractions from an already sensitive process. Despite the challenges, our efforts have paid off. As of January, all civil servants are now required to have professional project management training and qualifications. While "influencing the influential" was a business plan specifically tailored to Taiwan's situation and needs at that time, we were nevertheless following our own professional management training. As the A Guide to the Project Management Body of Knowledge (PMBOK® Guide) indicates, identifying your stakeholders and satisfying their needs would be the first step to successfully managing change, regardless or how big or small that change. |
Hey Boss, What About Work-Life Balance?
| The last hypothetical I posted, Is This Your Project Stakeholder? attracted a wide cross section of responses. It made me wonder what you think of this real life experience (only the names have been changed): Sebastian is a highly competent, upwardly mobile executive and your boss. He works 6 a.m. to 10 p.m., and is a very detailed person. He proofreads everything, making copious corrections and is also studying for his second master's degree. You have found the best time to approach Sebastian to discuss anything is after 8 p.m. when the office is quiet and he is working on his studies. In fact, at this time of night he seems to appreciate a brief chat. The problem is you have a "life" outside of the office and feel 8 a.m. to 6 p.m. is a very fair day's work. How would you approach building rapport with Sebastian to allow the discussion of important project issues and enhance your career prospects without waiting until after 8 p.m.? I will review all comments and based on your feedback I will suggest some solutions in my next post. |
PMBOK® Guide for the Trenches, Part 3: Cost
Categories:
Project Failure
Categories: Project Failure
| What would be your reaction if I told you there's a widely practiced profession out there that pays well, with (usually) nice working conditions, and it involves continuously providing its customers with the wrong answers? Welcome to the wonderful world of cost estimating. Take for instance, the original estimate for the National Ignition Facility project--it was just over US$1 billion. The final budget was US$4.2 billion. The Central Artery/Tunnel Project, also known as the "Big Dig," was originally estimated at US$2.8 billion. Through 2006, US$14.6 billion had been spent (though to be fair, this is only US$8 billion in inflation-adjusted dollars). The original estimate for the Sydney Opera House was US$7 million. The final cost was US$102 million, more than 14 times the original estimate. Why is estimating so tough? It's not as if estimators are dumb or poorly trained in their profession. I've earned my estimating certification, and that was one hard test--it melted my brain. I took the examination on a Friday and couldn't participate in light conversation for the following weekend. The reason that initial cost estimates seem to so rarely align with a project's final costs has nothing to do with the work quality of the estimators. It has to do with the work quality of everybody else on the project team. You see, comparing the final costs of a project to their original estimates is a way of making the cost baseline team somehow responsible for everything that went wrong in a project. In the case of the Sydney Opera House, bad weather, incomplete plans and drawings, and a lack of information about the material and the structure of its now-famous roof all added dramatically to the cost. The estimators didn't make those errors--other members of the project team did. I have to laugh every time I hear a project manager lament all that's really needed is a good cost estimate--as if a sufficiently prescient estimate would work as a talisman to ward off rate variances, contingency events, poor performance and scope creep. For those estimators who are reading this and can't believe your eyes, I figured I've spent enough ink lambasting you for hanging around projects and continually re-estimating the remaining costs as a way of providing project control capability. You deserve a break. I'm especially interested in hearing from those estimators and project controllers who somehow find themselves the scapegoat when their original cost baseline gets blown to smithereens. |
Power Scrum: Secrets to a Good Meeting
Categories:
Agile
Categories: Agile
| This is a guest post from Bill Krebs, owner of Agile Dimensions LLC The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way. The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more. So what goes wrong? And how can you get back the benefits? Here are some ideas. Focus There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates? Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear. Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem. The scrum meeting is not about status. It's about completion. Control the Number of Participants Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen. If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together. Go Offline Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?) In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting." Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement. Remember My Three A's: Awareness: The meeting is about knowing what your teammates are up to. Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day. Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion. Those tips will cut the fluff--and speed up your work! |