By Kevin Korterud
When I first started as a technology project manager, it was not uncommon for a project to have just one deliverable. All of the tasks in the project created the path that led to the single deliverable, which in many cases was a program, report or screen. Life used to be so easy!
As projects became more complex, the need grew for multiple project deliverables that lead to a complete solution. Deliverables now represent the “building blocks” that form a key foundational element of any project.
Whereas scheduling tasks is a fairly straightforward process that involves capturing durations, resources and successor/predecessor networks, scheduling deliverables comes with its own set of complexities. Deliverables don’t always behave in a linear manner like tasks—so special considerations come into play with their scheduling. In addition, there are typically people and expectation factors that need to be part of a deliverable scheduling model.
Here are three essential reminders for properly scheduling deliverables:
Whereas tasks are singular items that stand alone in a work plan, deliverables have a few extra packaging steps in their path to completion.
One of the most dangerous scheduling mistakes to make with deliverables is to have a single task in a work plan that represents the deliverable. This is because of the variation in duration and effort that it takes to complete a deliverable.
Deliverables have a natural path to completion that involves a package of tasks, whose dynamics differ from normal tasks in a work plan. Project managers need to include these extra tasks that chart the lifecycle of a deliverable from initiation to completion.
For example, a sample set of deliverable task packaging would appear as follows:
You can tell from the above table that prior to scheduling deliverable task packages, project managers need to have a deliverable governance process in place. A deliverable governance process that identifies specific deliverable reviewers and a single approver are key to the effective scheduling of deliverables.
2. Deliverables May Require Task-like Linkages
We are all familiar with creating predecessor or successor linkages between tasks to form a linear series of work needed to achieve an outcome. Those linkages serve to drive schedule changes as prevailing project conditions occur.
Deliverables can require the same sort of linkages found in tasks. For example, if you have deliverables that lead to the creation of a marketing web page that involves multiple supplier deliverables, selected tasks in the deliverable package can contain task linkages. These linkages impose conditions which determine the pace at which related deliverables can be completed.
Let’s say there are three design documents from different suppliers required to create an overall design document. The build of the overall design document cannot finish before those three supplier design documents are all approved. So in the work plan, delays and schedule movements in the supplier design deliverables will drive the true completion date of the overall design document.
In addition to the scenario of having deliverables with dependencies, it is just as likely to have a set of deliverables that do not have any dependencies at all. These deliverables need to be completed by the end of the project but do not directly figure into the final outcome of the project. These are often process improvement deliverables that are needed for future projects that are not ready for execution.
When a project manager has a slate of unrelated deliverables, the optimal approach is to bundle them into agile-like sprints. The content of each deliverable sprint is determined by a balance of resource availability for the people who build, review and approve deliverables, as well as any form of relative priority. For example, if deliverable reviewers have low availability during a scheduled deliverable sprint, those deliverables can be pushed to a subsequent deliverable sprint.
Priority can also determine the content of deliverable sprints. Higher priority deliverables would displace lower priority deliverables to future sprints, even if work has begun on those deliverables. For example, if there is a strong need for a certain tool to be used by multiple projects, those deliverables would move into the current deliverable sprint. The deliverable sprint process allows for agility, while balancing value created from the deliverables.
As I shared earlier, life was so much easier when projects created one deliverable. Different times demand different approaches to managing deliverable schedules—especially on large transformations where there could be hundreds of dependent and independent deliverables. The last thing anyone wants to do is insufficiently manage deliverables: Leaving out one of those “building blocks” might cause the house to fall over.
What tips do you have for deliverable scheduling in today’s project ecosystem? Share your thoughts in the comments below.
By Ramiro Rodrigues
Is risk management just an exercise in paranoia?
That’s the question I’m often asked. I like to respond by saying there are both negative and positive risks.
A risk is a situation in which it cannot be certain whether a specific result will happen. That potential cannot be discounted. Thus, any risk hypothesis—whether for small or large risks—is subject to some sort of management strategy. While we often think of negative risks, positive risks present opportunities for organizational or project gains.
Risk management strategies can be applied to our daily lives. Take, for example, my own experience.
A few years ago, I was invited to hold a workshop on project management best practices for a service company. Concerned about the event, I decided to invite a colleague whom I trust to share the work (strategy: share) and increase the chances of the workshop being successful (strategy: improve). When checking his schedule, my colleague realized that he would be returning from a trip at 6 a.m. on the day of the workshop, which was scheduled to start at 9 a.m. Even knowing that flight delays are more common than we would like, we decided to take the risk (strategy: accept).
In the weeks leading up to the event the preparation flowed well. We met with the client and tested the presentation dozens of times (strategy: explore), but the possible flight delay did not leave my mind. For this reason, I studied not only my part of the presentation, but also that of my colleague (strategy: eliminate).
When the day arrived, I woke at 6 a.m. to find two messages from my colleague on my phone. The first one said, "I've landed?” This gave me a sigh of relief. The second said, "I'm really ill. I'm going to a hospital.” I called my colleague and verified the illness.
What a great irony! All my fears arising from my colleague's risk of a delayed flight were realized, but not because of that event.
Some changes were necessary. First, I had to substitute the car journey with a taxi (strategy: transfer). Second, I had to remove specific parts from the presentation to reduce the impact of my colleague’s absence (strategy: mitigate). Even without doing so through a documented plan, I had used all of the recognized risk response strategies.
For me, it became clear that the great gain from risk management is in the exercise of thinking beforehand and being able to choose the best options available.
The outcome of the workshop? I imagine it would have been better if my colleague had been able to attend. But judging from the applause and words of praise, I believe that it was a success.
by Kevin Korterud
The technology found in today’s automobiles is simply amazing. Front and side traffic radar units, anti-dozing head movement detectors, driving timers that alert drivers when they should stop for a break — all good examples of accident prevention mechanisms.
Projects to some degree are like automobiles: They are on a journey to deliver passengers (the project team and stakeholders) to a pre-determined destination. However, despite the introduction of many modern project management technologies, research shows that we continue to experience project accidents. These accidents result in extensive and costly rework to get a project back on track.
I think part of the solution to avoid these potential problems is to borrow from recent automobile technologies as a way to detect troublesome signals. These signals are not readily perceivable from traditional project management methods.
Here are a few examples of anticipatory signals that portend the onset of a skid that often leads to a project accident.
A core competency of a project manager is to determine the schedule, budget and progress trajectory of a project. The project forecast is essential to determine where the project will finish for these measurements. Schedule, budget and progress forecasts from team members that exhibit great degrees of change over prior reporting periods are indicative of trending to an accident. This downward spiral is exacerbated when the forecast measurements come with great uncertainty; e.g., “I don’t know what this will take to finish.”
Several techniques can be employed to reduce the volatility of forecasting. Some of these techniques include initiating a peer review of the forecast with another project manager or supplier subject matter expert, as well as pausing the project to recalibrate the forecast in a dedicated working session. Taking time to implement these and other techniques to mitigate forecast volatility will get the project back on track before an accident.
2. Static Project Status
Project status reports can offer a tremendous amount of value to a project manager. They accumulate both qualitative and quantitative data that sheds light on the current project state. But, despite the visibility status reports provide, they’re just a snapshot. That limits their ability to show progress trends. In addition, a project status report that does not show content changes week over week indicates that the project is likely stalled and headed toward an accident.
To increase the anticipatory value of a project status report, introduce trending and predictive data for risks, issues, deliverables and milestones. This allows the project team to determine what level of progress has been achieved, as well as what progress to expect. It also better positions the project manager to escalate mitigations to avoid an impending project accident.
At the beginning of a project, stakeholder engagement and enthusiasm is typically high. This is not unlike the start of a road trip. But, as time passes on a project, the level of enthusiasm and engagement can begin to wane. Stakeholder engagement over time will face tough tests from project risks to resource challenges to dependency conflicts. Each can sap the energy levels of stakeholders. This leads to passive engagement at best and complete disengagement and absenteeism at worst.
To keep stakeholder engagement at the proper level, stakeholders need to be treated like any other resource on a project. Their time needs to be managed in work plans to avoid oversubscribing their capacity. In addition, their work should be focused on higher value activities that promote project progress. Providing the team access to project support staff to maximize productivity also helps further stakeholder engagement and leads to persistent engagement.
Perhaps one day in the future there will be technology solutions that provide anticipatory signals for projects headed for an accident. Until that day comes, however, project managers still need to think organically and look for hidden signals of dangers to project budgets, schedules and progress.
What do you see as the leading indicators that a project is trending toward disaster?
High-Performance Teams Are Purpose-Driven
Education and Training,
Human Aspects of PM,
New to Project Management,
Nontraditional Project Management,
Reflections on the PM Life,
Categories: Benefits Realization, Best Practices, Career Help, Change Management, Communication, Complexity, Education and Training, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, Mentoring, New to Project Management, Nontraditional Project Management, Program Management, Project Delivery, Project Failure, Reflections on the PM Life, Risk Management, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis, Ph.D., M.B.A.
Program teams should collaborate like a world-class orchestra.
This ideal state of team engagement and performance requires the presence of several key elements, including an engaged sponsor, a governance committee, a project manager and a status dashboard to communicate performance.
However, maximizing this level of performance is especially challenging when working with cross-functional groups, external stakeholders and shareholders. This increases the complexity of the human performance aspects of team management.
I recall one assignment I worked on that required the team to design and build a new centralized model to bring together three different operations. The team was given two additional challenges. The first challenge was to consolidate disparate teams into two geographic centers. They also had to reduce the overall timeline from 18 months to 10 months.
These challenges exacerbated how teams were not working well with their counterparts. They quickly became dysfunctional and lost their purpose. The project was crashing.
Stepping into this situation I decided to conduct a stakeholder analysis. I used this approach as an intervention method to understand the underlying themes. The analysis revealed the team:
After reflecting on the team’s feedback, I realized that most members wanted to find meaning in their work. It seemed no one was developing their sense of shared purpose and putting their strengths to work toward this program.
I decided I needed to re-invest them as members of the team. To get the team back to performing well, I:
This approach strengthened the program and delivered on the challenges.
The lesson learned is, do not simply apply methods and approaches in complex program delivery. Manage the team’s purpose and establish shared values as an important driver of overall delivery.
How do you manage that purpose and invest in high-performing teams?
3 Tips to Enhance Your Leadership IQ
Education and Training,
Human Aspects of PM,
Reflections on the PM Life,
Categories: Benefits Realization, Best Practices, Career Help, Change Management, Communication, Communication, Complexity, Education and Training, Ethics, Facilitation, Human Aspects of PM, Human Resources, Innovation, Innovation, Leadership, Leadership, Lessons Learned, Lessons Learned, Mentoring, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Risk Management, Roundtable, Social Responsibility, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
The boards I serve have common opportunities and challenges revolving around promoting a brand, balancing the operating budget and growing capital. Yet, while flawless leadership is expected, in actuality it is difficult to sustain.
As I reflected on why many organizations were challenged around execution, I realized that executives must improve their leadership intelligence around three key factors to enable success:
In my experience as a mentor and leadership coach, these tips can help align decision-making, leader accountability and stakeholder engagement to the needs of the customers, and improve the overall culture of the organization. As a result, the brand will come to life.
How have you improved your leadership intelligence?