Q: Everyone tells me to pad my project estimates. Should I follow their advice?

A: No! You should share your best, most accurate and non-altered estimates with your sponsor. Padding your estimate is adding contingency without justification. Be transparent. Share estimates with your sponsor, emphasizing that they don’t include contingency.  Then, share your recommendations for how much contingency to add based on specific risks associated with the project.

For more on project management, check out the Become a Project Manager Learning Path at LinkedIn Learning.

Collaboration is gold in projects. Collaborative stakeholders produce better requirements, provide support for your solution, and rarely raise issues when accepting deliverables. Even with these benefits, there can be too much collaboration. Here are symptoms of too much project collaboration and how to correct them:

• You have more stakeholders than necessary. Environments that are extremely collaborative can bring a wide variety of hopes, expectations, and opinions – more than needed for success. When many stakeholders want to collaborate, assign primary stakeholders and secondary stakeholders (more like interested parties). Restrict project authority like submitting formal requirements or decision-making to your primary stakeholders.
• Decisions take too much time.  As stakeholders seek to include others, decision-making can get dragged out. While including everyone can help produce better decisions, timeframes for reaching those decisions can be too long. Lack of consensus can cripple a project. To address this, include review time and decision-making tasks in your project schedule. Emphasize when decision-related tasks are on your critical path and discuss the impacts of extended decision-making time.
• Scope increases. As stakeholders participate in requirements sessions and your solution comes to fruition, new ideas for adding business value can arise. The more the collaboration, the more this will occur! While business value is a good thing, your scope might grow beyond your “minimum viable product.” Ensure your change approval process focuses on limiting project scope to what’s needed to deliver business value. Remind stakeholders that Phase 2 of the project can be evaluated and cost-justified to accommodate the new business value ideas.
• It’s difficult to get approval to proceed or implement your project deliverables. If you hear lots of “it’s ok with me, but please check with x” responses, you may have an approval process issue. Ensure you have agreed upon processes for approvals built into your Project Charter, including who has final approval.

To learn more, see “How organizational culture affects projects” in my LinkedIn Learning course, Project Management Foundations.

Q: My sponsor asked me to prepare the justification for a project. Is that appropriate or should my sponsor do this work?

A: The Project Management Institute (PMI) holds the sponsor responsible for project justification. However, sponsors can delegate project-related responsibilities to the project manager. So a PM justifying a project is appropriate as long as the sponsor provides appropriate support. In that case, you should consider the request a compliment regarding your PM skills and trust in your abilities.

Some people think from the top down and consider the high-level deliverables or activities required to accomplish project objectives. Others take a bottom-up approach, focusing on details that must be completed. When building a work breakdown structure (WBS), use these differences to your advantage.

Here’s how to leverage top down and bottom up thinking when building a WBS:

1. Sketch a high-level set of activities or deliverables. A WBS is built by grouping similar activities or deliverables. The key is to be consistent and not mix the two constructs. Use your best top-down thinkers to create a high-level grouping for your project. Give your team time to consider major items that fall into each group. These major items can be broken down further as appropriate.
2. Review and align with your team. Develop a common understanding of the work that the WBS represents and ensure there is no duplication of the major items captured in this initial version of the WBS. (Senior team members confer to determine whether there is duplication.) Determine how much detail is required to complete the WBS and determine the best individuals to add the necessary detail.
3. Draft the detailed tasks for each major item. Now is the time for your bottom-up thinkers to shine! Bring your team together and brainstorm the tasks that must be completed to deliver your project. Allocate those tasks to the appropriate major items. Identify and resolve activity overlaps or duplications that may surface. Note: Your team doesn’t have to worry about sequencing your tasks at this point. Sequencing will be done later during schedule development.
4. Finalize the WBS. Gather your team and review the final, detailed draft of the WBS. Talk with your top-down thinkers to ensure the overall approach is sound. Your bottom-up thinkers should be confident all the details are covered. If everyone is happy, you’re done!

Note: For more complicated projects or if significant questions arise, you can repeat steps 2 and 3.

For more about project management, check out my LinkedIn Learning Project Management Foundations course.

Not every project is suitable for agile. To succeed with agile be sure to use sound criteria to qualify your projects as good agile candidates. Here are things to consider when establishing your agile qualification criteria:   

• Project priority to obtain the right staff. Having the appropriate technical and business team members dedicated to the project is crucial. Agile produces results quickly and it’s time-intensive for participants. Agile requires critical business and technical team members who are vital to your business operations. So it’s important to prioritize their time so they can contribute to the project. Accepting the difficult tradeoffs between project work and operational considerations is key.

• Appropriate breadth of knowledge. In-depth knowledge of the business and technical areas touched by the project is crucial. Business experts working closely with expert technical team members is the heart of the agile approach. The primary characteristic that makes agile methodologies agile is the method’s responsiveness to evolving needs. Knowledgeable technical and business people need to consistently reassess the project’s product, the business’s needs at a macro and micro-level, and the priority of the functions needed by the end customer. Without knowledge and availability for those assessments, the premise of agile methods crumbles.

• Sponsor with an agile mindset. The sponsor must be willing to participate in frequent reviews of the evolving product, which are fundamental to the agile approach.  On the other hand, a sponsor who wants a linear, methodical set of objectives delivered to a pre-conceived schedule will struggle with agile project deliverables. Agile responsiveness to changing business conditions and its learning environment are very different from traditional project methods. Sponsors who resist evolutionary nature of agile create difficulties that can sink a project.

• Ability to co-locate or simulate co-location. Agile involves deep, interactive, and sometimes challenging dialog, which produces superior outcomes. Getting the most from that dialog requires the richest environment you can create. Co-locate your project team members if possible. If you can’t, simulate co-location with the best video and audio tools you can obtain. Trying to facilitate agile dialog with sub-par communication tools is like trying to tow a big camper trailer with a lawn tractor. It just doesn’t make sense.
• Business and technical team member synergy.  Agile methodologies require dedication from business and technical experts open to supporting new ideas and each other as individuals. You need an agile coach who understands and can manage human dynamics, and who can foster an environment where team members readily share their ideas and concerns. An agile team has to get along well to be successful.

• A product that can be built iteratively. Agile’s best qualities come from delivering solutions in pieces while learning from each iteration. In addition to software products, other products can be produced this way as well. With a bit of creativity, facility moves, new process implementations, and even some construction projects can utilize agile methods. If you think of a way that your outcome can be produced in iterative steps, the project may be a candidate for agile (given the other items listed here, of course!)

For more about project management, see my Project Management Foundations course.