Home
/
Blogs
/
Voices on Project Management
/
Voices on Project Management
by Cameron McGaughy,
Lynda Bourne, Kevin Korterud, Conrado Morlan, Peter Tarhanidis, Mario Trentim, Jen Skrabak, David Wakeman, Wanda Curlee, Christian Bisson, Ramiro Rodrigues, Soma Bhattacharya, Emily Luijbregts, Sree Rao, Yasmina Khelifi, Marat Oyvetsky, Lenka Pincot, Jorge Martin Valdes Garciatorres, cyndee miller
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
View Posts By:
Cameron McGaughy
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres
cyndee miller
Past Contributors:
Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie
Recent Posts
Project 2030: Skills We Need to Cultivate Now
The Technical Program Manager: How to Stay Relevant in 2025
5 Things Your Operational Plan Should Do
5 New Project Guardrails for Adaptive Leaders
The Leader's Voice: Respect It, Protect It, and Use It Properly!
Categories
2020,
Adult Development,
Agile,
Agile,
Agile,
agile,
Agile management,
Agile management,
Agile;Community;Talent management,
Artificial Intelligence,
Backlog,
Basics,
Benefits Realization,
Best Practices,
BIM,
business acumen,
Business Analysis,
Business Analysis,
Business Case,
Business Intelligence,
Business Transformation,
Calculating Project Value,
Canvas,
Career Development,
Career Development,
Career Help,
Career Help,
Career Help,
Career Help,
Careers,
Careers,
Careers,
Careers,
Categories: Career Help,
Change Management,
Cloud Computing,
Collaboration,
Collaboration,
Collaboration,
Collaboration,
Collaboration,
Communication,
Communication,
Communication,
Communication,
Communications Management,
Complexity,
Conflict,
Conflict Management,
Consulting,
Continuous Learning,
Continuous Learning,
Continuous Learning,
Continuous Learning,
Continuous Learning,
Cost Management,
COVID-19,
Crises,
Crisis Management,
critical success factors,
Cultural Awareness,
Culture,
Decision Making,
Design Thinking,
Digital Project Management,
Digital Transformation,
digital transformation,
Digitalisation,
Disruption,
Diversity,
Diversity,
Documentation,
Earned Value Management,
Education,
EEWH,
Enterprise Risk Management,
Escalation management,
Estimating,
Ethics,
execution,
Expectations Management,
Facilitation,
feasibility studies,
Future,
Future of Project Management,
Generational PM,
Governance,
Government,
green building,
Growth,
Horizontal Development,
Human Aspects of PM,
Human Aspects of PM,
Human Aspects of PM,
Human Aspects of PM,
Human Aspects of PM,
Human Resources,
Inclusion,
Information Technology,
Innovation,
Intelligent Building,
International,
International Development,
Internet of Things (IOT),
Internet of Things (IoT),
IOT,
Knowledge,
Leadership,
Leadership,
Leadership,
Leadership,
Leadership,
lean construction,
LEED,
Lessons Learned,
Lessons learned;Retrospective,
Managing for Stakeholders,
managing stakeholders as clients,
Mentoring,
Mentoring,
Mentoring,
Mentoring,
Mentoring,
Methodology,
Metrics,
Micromanagement,
Microsoft Project PPM,
Motivation,
Negotiation,
Neuroscience,
neuroscience,
New Practitioners,
Nontraditional Project Management,
OKR,
Online Learning,
opportunity,
Organizational Culture,
Organizational Project Management,
Pandemic,
People management,
Planing,
planning,
PM & the Economy,
PM History,
PM Think About It,
PMBOK Guide,
PMI,
PMI EMEA 2018,
PMI EMEA Congress 2017,
PMI EMEA Congress 2019,
PMI Global Conference 2017,
PMI Global Conference 2018,
PMI Global Conference 2019,
PMI Global Congress 2010 - North America,
PMI Global Congress 2011 - EMEA,
PMI Global Congress 2011 - North America,
PMI Global Congress 2012 - EMEA,
PMI Global Congress 2012 - North America,
PMI Global Congress 2013 - EMEA,
PMI Global Congress 2013 - North America,
PMI Global Congress 2014 - EMEA,
PMI Global Congress 2014 - North America,
PMI GLobal Congress EMEA 2018,
PMI PMO Symposium 2012,
PMI PMO Symposium 2013,
PMI PMO Symposium 2015,
PMI PMO Symposium 2016,
PMI PMO Symposium 2017,
PMI PMO Symposium 2018,
PMI Pulse of the Profession,
PMO,
PMO,
pmo,
PMO Project Management Office,
portfolio,
Portfolio Management,
Portfolio Management,
portfolio management,
presentations,
Priorities,
Probability,
Problem Structuring Methods,
Process,
Procurement Management,
profess,
Program Management,
project,
Project Delivery,
Project Dependencies,
Project Failure,
project failure,
Project Leadership,
Project Management,
project management,
project management office,
Project Planning,
project planning,
Project Requirements,
Project Success,
Ransomware,
Reflections on the PM Life,
Remote,
Remote Work,
Requirements Management,
Research Conference 2010,
Researching the Value of Project Management,
Resiliency,
Risk Management,
Risk Management,
Risk management,
risk management,
ROI,
Roundtable,
Salary Survey,
Schedule Management,
Scheduling,
Scope Management,
Scrum,
search,
SelfLeadership,
SelfLeadership,
SelfLeadership,
SelfLeadership,
SelfLeadership,
Servant Leadership,
Sharing Knowledge,
Sharing Knowledge,
Sharing Knowledge,
Sharing Knowledge,
Sharing Knowledge,
Social Responsibility,
Sponsorship,
Stakeholder Management,
Stakeholder Management,
stakeholder management,
Strategy,
Strategy,
swot,
Talent Management,
Talent Management,
Talent Management,
Talent Management,
Talent Management,
Talent Management Leadership SelfLeadership Collaboration Communication,
Taskforce,
Teams,
Teams in Agile,
Teams in Agile,
teamwork,
Tech,
Technical Debt,
Technology,
TED Talks,
The Project Economy,
Timeline,
Tools,
tools,
Transformation,
transformation,
Transition,
Trust,
Value,
Vertical Development,
Volunteering,
Volunteering #Leadership #SelfLeadership,
Volunteering Sharing Knowledge Leadership SelfLeadership Collaboration Trust,
VUCA,
Women in PM,
Women in Project Management
Date
Viewing Posts by Marian Haus
| Projects are rarely planned and executed in isolation. In general, they have external dependencies on activities, tasks or deliverables outside the project's reach. Managing tasks and dependencies that spread across several projects, which are not necessarily part of a program, creates a multi-project management context.
For instance, say you are managing an IT project, delivering a software application. Many of your project tasks will be conducted within the project's boundaries and with the full control and ownership of your project team. Nevertheless, your project has dependencies on a software component, developed in parallel by another team within the same enterprise, yet as part of an entirely different project. Your project will have to wait for the other team to finish and deliver its component to deploy and test your software application. Since the two projects have phases and deliverables dependent on each other, their project schedules will have to be correlated.
Managing correlated schedules requires a different approach. In a single-project context, a project manager plans the schedule, giving consideration to the project context, the work to be carried out by the project team, assumptions, risks, and the tasks' internal and external dependencies. This is more or less a silo approach, where the external dependencies rely on deliverables and not on the project phases or cycles in which they are produced.
In a multi-project management context, the project managers involved, or an overseeing multi-project manager, will have to reach alignment across the projects in several aspects, including:
- Aligning project stages and deliverables depending on their interrelated dependencies
- Reaching agreements and locking down commitments for respective conditions, such as the quality of deliverables, meeting deadlines required for the touch points between projects
- Sharing risks and planning required measures together, in case one project negatively impacts the other
Let's go back to our previous IT project example, and how alignment could happen. The two projects start off independent of each other. Then they can have touch points during the requirements analysis and scoping phase, when your project team will analyze and hand over requirements and product specifications to the other team. Then the two projects will meet again during a joint testing phase, when both project teams will deploy and test their application components integrated together. Finally, the two projects will meet again during the go-live deployment, when the rollout of one project will not be complete without the rollout of the other.
The more touch points the projects have, the more complex their schedule planning will be. The stronger their dependencies, the less flexibility you will have when planning your project schedule. And the more relevant the other project is for your organization, the less planning flexibility and schedule control you will have on yours.
The situation gets even more complicated when your project depends on three or more other projects, which have different schedule plans, business criticalities and even project management approaches. For instance, your project is conducted in a waterfall methodology, and it's dependent on another project following an agile approach. It can become quite challenging aligning your waterfall schedule to the iterative and dynamic schedule of the other project.
What is your project scheduling experience with dealing with multiple projects that depend on each other?
|
Posted
by
Marian Haus
on: August 29, 2013 12:17 PM
|
Permalink |
Comments (3)
In past posts, I covered five steps for setting up a schedule planning framework and seven basic tips for building a project schedule.
In this final installment of this series, I'll discuss 10 common pitfalls of building a schedule on any project:
- The silo approach: Avoid developing the schedule in "silo" mode -- that is, without input from key stakeholders or subject-matter experts that can validate and confirm the schedule's content.
- Inappropriate tasks decomposition: When decomposing work in tasks, avoid an overly detailed decomposition or under detailed decomposition. In my experience, each task should not be shorter than two days and not longer than two reporting periods (typically two weeks). A task of this length is generally explicit, focused, actionable, assignable and traceable.
- Too many milestones: Limit milestones to significant project events or decisions -- for example, the project start, completion of major deliverables or phases and the project's end.
- Overly ambitious schedule: Everyone wants to please the customer, but an aggressive schedule can have the opposite effect if unrealistic deadlines are continually missed. Instead, aim to exceed expectations by delivering the project in a realistic timeframe, with solid execution. If you inherit an overly ambitious schedule, you could "fast-track" (i.e., make work parallel) or "crash" the schedule by assigning more resources to reduce task duration.
- Loops: A project schedule is not a flowchart, and time cannot flow in reverse. Therefore, loops, a circular task dependency, are not possible or validated by most project management scheduling software. Do not confuse loops with iterations. Iterations of tasks --such as design, implement and deploy -- are allowed on a project schedule.
- Danglers: These are the dependency links between tasks. Only one task will have no predecessor (the project start task) and only one will have no successor (the project end task). All the other tasks should have a successor and predecessor.
- Confusing tasks efforts with schedule time: Don't just ask team members: "When can you complete this task?" Instead, ask for the estimated effort to complete the task in labor hours or days. Then, transform the effort into work periods (the work days the team member can carry out the task) and map this to the project calendar (considering business days, holidays and vacation periods).
- Allocating schedule buffer instead of effort buffer: Don't allocate buffers to a certain schedule time. Task estimation is a three-step process: effort, duration and required calendar time. Allocate buffers primarily on a task's effort and not on the overall required calendar time.
- Depending on overall buffers: Avoid relying on sweeping buffers, like the classic "20 percent." When assigning buffers, consider the project-specific risks (for example, unfamiliar technologies), the experience of the project team and non-project related factors, such as resources allocated to parallel projects or team members' involvement in non-project activities.
- Wrong tasks on the critical path: Project management tasks, effort estimation tasks and other schedule planning activities should not be located on the critical path. They have nothing to do with the actual project work tasks.
How do you overcome these pitfalls, and what other schedule planning difficulties have you faced?
|
Posted
by
Marian Haus
on: July 12, 2013 09:53 AM
|
Permalink |
Comments (6)
In my previous post on project schedule planning, I referred to a five-step approach to setting up a schedule planning framework.
In this post, I offer seven tips on creating a schedule for any project:
- Focus on action. A project schedule is all about how deliverables will be produced. So after you break down work packages and deliverables, use active verbs to describe the smaller work tasks. For example, say "design webpage" instead of just "webpage designed."
- Keep tasks simple and compact. For a clear, clean project schedule, make task names short. If necessary, go into more details in an appendix or separate document to elaborate on each task and its outcomes.
- Create context. Also in a separate log, briefly document assumptions and constraints that accompany tasks. This helps in sequencing, linking and managing the tasks. For instance, if you know that a task needs to be executed in a certain timeframe, then you can better link, sequence or parallelize tasks.
- Diagram. A visual illustration of the task sequencing and relationship will help the team understand the task dependencies and anticipating when these dependencies should kick in. Additionally, a visual breakdown can help identify tasks that can be done in tandem (i.e., those that have no dependencies).
- Use the critical path. Apply information gleaned from the critical path to the schedule. The critical path is most helpful in monitoring delays or identifying opportunities to accelerate the schedule. If a task located on the critical path slips, the project can be delayed. If a task on the critical path can be shortened, the project schedule can get shorter. If the critical path's duration exceeds the project deadline, then reduce scope, reassess durations, improve estimates or increase team resources.
- Assess duration properly. When estimating task duration, distinguish between effort, duration and required calendar time to complete a task. The effort relates to the actual work required to complete the task (i.e., How many hours?). The duration refers to how many work periods are required to complete the effort (i.e., How many work days?). The required calendar time means mapping the work days on a calendar that includes holidays and vacation periods.
- Combine duration methods. Related to the sixth tip, combine multiple methods to assess duration. Take into account estimations from past projects and apply parametric estimation. For instance, if you use the three-point estimation (i.e., pessimistic, optimistic and most likely), find the theoretical estimation based on current expectations — but in addition, incorporate estimates from similar past tasks or projects.
What other tips help you when building a project schedule that can apply to any project?
|
Posted
by
Marian Haus
on: May 21, 2013 09:39 AM
|
Permalink |
Comments (8)
| Technically speaking, the project schedule is a key project planning component. But practically speaking, simply creating a project schedule does not guarantee project success. Project success requires the project manager to plan out a reliable, comprehensive and realistic schedule.
The following three-pronged approach helps in creating such a schedule: set up a schedule planning framework, master schedule basics and run the project avoiding the classic schedule planning pitfalls.
In this post, I will shed some light on a simple schedule planning framework. Effective schedule planning boils down to five basic steps:
- Plan. Identify which sources and resources will provide the project schedule information, such as the scope baseline, scheduling takeaways from similar previous projects and subject matter experts. Select the appropriate software tool to manage the schedule. This could be a standard project management tool used by your company, or it can be one you have selected considering your project's level of complexity, reporting automation needs and team collaboration requirements.
- Develop. Break down the work packages and deliverables into actionable tasks. Identify key milestones, such as completion of major deliverables or project phases. Sequence tasks logically, depending on their execution order and dependency on other tasks. Match team members to each task with their corresponding skills. Assess task efforts and all project time based on historical data from a similar project, or using techniques such as the Program Evaluation and Review Technique (PERT).
- Validate. Work with subject matter experts to review and validate the developing schedule.
- Follow through. After creating a baseline project schedule, track the completed tasks and achieved milestones. Developing a project schedule is not a final destination -- it has to be maintained.
- Adjust. You will rarely finish the project by following the exact schedule plan you began with. Adjust the schedule as you go by exploiting the opportunities that arise (such as fast-tracking activities or finishing work earlier, if possible), or taking corrective actions when faced with delays or unexpected activities (such as enlarging the team or "crashing" activities).
What are your must-do steps when creating a project schedule? What scheduling framework has been successful for you?
|
Posted
by
Marian Haus
on: April 10, 2013 11:13 PM
|
Permalink |
Comments (14)
| Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value.
Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals.
The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components.
As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:
- Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
- Spreading deliverables across knowledge areas. Project teams organized by areas of expertise (such as operations, legal or finance) usually use this technique in their projects.
- Spreading deliverable across processes. This is typical for process-oriented projects.
- Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole.
- Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.
To decompose requirements effectively, I recommend following these tips:
- Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
- Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
- Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results.
- Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
- Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it.
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.
How do you decompose requirements?
|
Posted
by
Marian Haus
on: January 18, 2013 04:48 PM
|
Permalink |
Comments (1)
|
"The reason why worry kills more people than hard work is that more people worry than work."
- Robert Frost
|
