Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Building Blocks of Project Work Planning
Categories:
Project Planning
Categories: Project Planning
| In my previous posts, I laid out the basics, the framework and the key documents for planning a project end-to-end. Now it's time to dive deeper. One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project. Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units. The building blocks of project work planning have four main steps:
The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information. Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs. The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries. The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project. Do you agree with these steps? How many steps do you use for project work planning? Read more posts from Marian Haus. |
How to Handle Your Project Management Mistakes
| My mother used to have a Charlie Brown pin that said, "I've never made a mistake in my life. I thought I did once, but I was wrong." I'm not as oblivious to my mistakes. In fact, I have made quite a few, both personally and professionally. In some cases, my gut told me I was making a mistake, but I went ahead anyway. Other times, I forged ahead confidently, only to be jarred by the sudden reality that I'd done something wrong. This happened recently at work. I got called into the proverbial "principal, or headmaster's office" and learned something I'd done caused trouble at a sister company. Not intending to make waves, I had started a tsunami. If you're a new project manager, it shouldn't be a surprise that you may make some mistakes. What do you do when you are called in to discuss your fallibility on the job? I sat and listened to the grievance presented to me -- staying calm is always the best approach. I absorbed everything my organizational leader shared with me. The first thing I said was, "I'm sorry." I briefly explained my side of the story without fanfare or drama. If you can explain yourself with brevity, do. Rambling probably won't work in your favor. I made it clear that I understood the other side of the story and guaranteed that I would be extra diligent in the future to avoid such mistakes. I wasn't defensive. I wasn't full of ego. I recognized my part in the issue and accepted the blame, as hard as it was. My organizational leader was professional, but she also expressed her dissatisfaction and disappointment in my behavior. This was the hardest thing to hear. The importance of being able to receive harsh criticism is not touted enough. The ability to hear -- and accept -- when someone else points out that you failed goes a long way in helping you establish a fruitful project management career. Afterward, my organizational leader followed up by saying she trusted that I had learned my lesson and would make better decisions going forward. She appreciated hearing my side because she now had full context of the incident. Before leaving, I asked if there was anything else I could do. In my case, the answer was no, but if there are action items for you, be diligent about accomplishing them in a timely manner. Give feedback to your organizational leader about your progress. Making a mistake as a professional is embarrassing, but most times, your career will go on. Deal with the mistake professionally and with integrity for a chance to be even better at what you do. |
Empower Project Team Members
| Project teams are built of people with multiple layers of skills and competencies. A few will be selected as project leads to have less responsibility than a project manager, but more than a team member. Project leads ensure smooth task management and reporting flow, but how many of them are allowed or trusted to make decisions? What level of decisions can they make? The key to empowering a team member lies in the project manager's ability to get to know the person's strengths and weaknesses. Some people, although highly skilled, are weak at managing customers. Some have the ability to influence but aren't necessarily good at managing time. In one of my earlier posts, I talked about delegating work to team members as a way to help them succeed. To be able to delegate effectively, project managers simply cannot pick one person and assign him or her a task without carefully considering that person's skills. When empowering team members, the same rules apply. In some cases, you can only see the true colors of a person through action. First, select someone with a suitable background and competencies. Then test the person with small decisions or tasks. Check if he or she can communicate effectively by having conversations to gauge his or her ability to think and act proactively. When you empower team members by giving them greater responsibility, you can significantly improve the way a project is managed. Deadlines that require input or quick decisions can be met promptly, for example. Customer satisfaction can be improved because a team member doesn't have to go through layers of approval. And, those empowered team members may get a confidence boost. What decisions do you trust your team members to make? Have you experienced any negative impacts by empowering team members? Do you think empowering team members improves project delivery? |
Persuade Stakeholders for Effective Project Governance
Categories:
Stakeholder Management
Categories: Stakeholder Management
| One of the biggest challenges faced by all sectors of the project management profession is persuading senior executives to focus on implementing effective project governance. Governance is a "top-down" process. Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed. Effective project management delivers a realistic and achievable outcome efficiently. If the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation from deteriorating further. Failure is guaranteed. Wishful thinking is not an effective substitute for effective project governance. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not have a miracle process that will magically transform an impossible set of objectives into an achievable set of objectives. The organization's executives need to balance risks, rewards and capabilities to set realistic objectives and then use effective governance systems to oversee the delivery. The only way to achieve meaningful change is by communicating to affect a change in the understanding of stakeholders. When senior executives require effective project governance, we can better assist them in establishing effective and robust systems. If you're lucky enough to work in an organization with effective project governance, broadcast the benefits. If you work in an organization that could improve its governance, use your skills to advise upwards. If your organization is on the road toward effective governance, keep helping it along. If we are successful in making effective project governance the normal way organizations operate, the rate of project success will increase, as will the standing of our profession. What can you do to help create the climate for better governance? |
4 Metrics to Help Spot Trouble for Agile Teams
| In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips: Juggle Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time. Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions. Plan leak This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning. Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work). In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates. Execution leak Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less). Jelly This shows how much unplanned work was added during the iteration. In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints. What do you think? Have you used these metrics? What metrics do you use to help spot trouble? |