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! |
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? |
