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! |
You Are What You Acknowledge!
| Almost everyone knows the saying, "You are what you eat." But Michael E. Case, president and CEO of The Westervelt Co., a land resource organization, put a new twist on it by saying, "You are what you acknowledge." In order to see something great in another, you have to have some experience with that quality or talent yourself. To admire and praise a team member's dedication and value as a human being to your team, you have to know on some level what it is to feel valued and to make a contribution to a team. When project team members show they respect and appreciate fellow team members' commitment, integrity, openness, positive attitude, expertise, knowledge sharing and listening, that's what becomes the team's--and even the organization's--core values. When these core values are brought to light, team members listen, they don't tolerate serving their customers poorly and they have a high sense of integrity. They become what they acknowledge. Leaders must set the example in order to have others emulate it and make it positively "rampant" in an organization. And by the definition of former Chairman and Chief Executive Officer of JP Morgan Chase, William Harrison, Jr., everyone can do this. He dramatically stated, "Be a leader. We want everybody to be a leader...to be a leader you have to have a view, be willing to constructively express it, and use it to make something better. Under that definition, everybody can be a leader." Everyone, then, not only can be, but IS a leader. Everyone, then, can demonstrate that ability to make something better. Team leaders who focus on and make it their honor and their duty to exemplify the power of acknowledgment achieve great results. Those of us who are acknowledged find it much easier to acknowledge others. Acknowledgments truly transform both the giver and the receiver on a project team. They engender employee loyalty and engagement, improve relationships and enhance self-worth. These positive results are contagious, and the actions of each team member are amplified as the recipient picks up on this idea and spreads the circle wider. Like pebbles in a pond, the ripples radiate farther and farther out. You are indeed what you acknowledge! Why wait to start practicing this--as a leader, do it now and reap the rewards! |
The Value of Reports
Categories:
Communications Management
Categories: Communications Management
| Developing reports is an art form--and it's one that every project management office manager needs to master. Well-designed reports contain large amounts of useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon. That information also allows stakeholders to extract trends and status. And if you deliver them in person or attach a note to highlight specific issues or messages, reports can form the basis of a targeted, purposeful communication. Some people simply like getting reports--and dropping those people off your distribution list make them more upset than you realize. This also applies to cutting content. As a rule of thumb, by the third month it's probably too late to remove sections or drop recipients without encountering some issues. Another benefit of reports is only starting to be recognized. Jon Whitty of the University of Southern Queensland here in Australia has been measuring the emotional effect of project artifacts. Based on Jon's work it seems a well-formatted report will in itself increase positive emotions. The project manager feels comfortable because she or he has a "proper report'' that is part of the "clothing'' every project manager wears along with their Gantt charts and other expected artifacts. And senior managers experience positive emotions because the existence of a well-presented report suggests control, order and capability. The challenge is to design reports that are relatively easy to produce, ask the right questions, are well-structured and well-formatted, and contain needed data. What are your experiences with reports? |
A PMBOK® Guide for the Trenches, Part 2: Schedule
| Last time in my post, PMBOK® Guide for the Trenches, I discussed scope. Now, I'd like to cover some basic truths about schedules that project managers need to know, but won't find in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). One vital truth that the PMBOK© Guide is clear on is that scheduling is only one aspect of effective project management, along with scope, cost, risk, communication, procurement, human resources, quality and integration. But you won't hear that from professional schedulers--no, no, no. It's often believed that the central tenet of project management is the ability to resource-load a schedule baseline into one of the more robust software packages that perform critical path analysis. This is part elitism and part what I refer to as "black box syndrome." Project team members are led to believe that if a certain software package is fed all the data it needs, then the push of a button will deliver all the management information needed to successfully complete a project. This, of course, is hokum, but I've seen it in many a project management office. On the other side of the coin, it's a fundamental truth that you cannot manage a schedule with a list of milestones or action items, no matter how elaborate that list may be. What tends to happen with action item lists or databases is that they essentially turn into, , polls and polls are not legitimate management-information systems. With a poll, there's always someone who has more recent information or more complete information than what's in "the system," rendering the data there unactionable. Note that I said the data in the system. There's a profound difference between data and information. Legitimate management-information systems process data into information using some kind of methodology. For schedules, this method is critical path. And it's a safe conclusion that there is no legitimate schedule management without critical path. For serious project work, a critical path network is absolutely essential. This no doubt contributes to the phenomenon of schedulers thinking critical path management is all that is essential in project management, with the other stuff kind of ancillary. I'm looking forward to everyone's comments. |
