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 Conrado Morlan
Project management practitioners know the importance of communication during the project execution, hand-off and operations stages. For each of these, the communication plan should cover all the different forms of communication and the target stakeholders.
The frequency of communication during project execution often has a defined cadence and uses different artifacts to deliver the message to stakeholders, who usually are internal.
During the operations stage, the project is usually in production and practitioners are communicating directly with customers, either internal or external. While the specifics depend on the situation, communication with customers must be regular, concise and delivered in a timely manner through the proper channels.
How Not to Communicate
As I did not meet the pre-registration requirements, the open registration was my only option. On registration day I was ready: My account was available, all my personal information was filled out, and I had my credit card on hand. At the designated time I visited the registration website to compete for a spot with thousands of runners from across the world.
I thought I would be directed to start the registration process, but instead, I was directed to an electronic queue page. After a few minutes, my expected waiting time was listed as 25 minutes. I got a little anxious thinking that the limited number of entries would sell out in less than that time. A few minutes later, the waiting time changed to 40 minutes, then to more than an hour; all of a sudden a message about “experiencing technical difficulties” was displayed.
In the meantime, upset runners from across the world took to social media to vent their frustration and dissatisfaction. But the organizers did not acknowledge the blast of posts until three hours after the designated registration time. That’s when they posted a message stating that they were trying to figure out the problem, and if they were not able to resolve it soon, a new registration date would be announced.
That message ignited the runners, who inundated social media with posts venting their resentment.
By this time, the organizer’s website was down, and the homepage showed the “experiencing technical difficulties” message. I stayed away from the postings on social media and kept refreshing the website persistently.
Finally, five hours after registration began, the website came alive and the new registration time was posted. I checked social media for postings from the organizer but found nothing. Right at the new posted time, I started my registration process while thousands of runners kept venting their frustration. This time it only took me 20 minutes to complete my registration for the Popular Brooklyn Half.
The Project Management Takeaway
In general, production problems have a resolution time window, which may vary depending on the seriousness of the issue. This is usually unknown for customers, but that does not hinder the communication process. We as project management practitioners need to consider that we are living in times dominated by instant gratification; customers expect that issues will be resolved immediately. At the same time, they expect frequent progress status reports.
As a project management practitioner, have you experienced a similar situation? If so, what did you do to keep your stakeholders/customers informed? What channels of communications did you use? How effective were they? Share your experiences with the community.
By Kevin Korterud
It’s quite possible that, if asked to remember every project I led over the years, I would be hard-pressed to do so. Our typical project management journey takes us down a new road when we complete a project, so we’re never really stopping to take a retrospective on how each one shaped who we are today.
A much easier exercise for me is to recollect which projects played a significant part in shaping my journey as a project manager. These projects, not unlike silver polish, brighten our skills and capabilities to a shine that allows us to undertake even larger and more complex projects.
Here are three projects that had a profound impact on my capabilities, and what I learned from each:
Up till a certain time in my project management career, I felt that my work included some rather large projects in terms of team members and scope. However, nothing prepared me for the massive construct that is a transformation program involving almost 2,000 people.
Transformation programs extend well beyond the realm of what project managers normally lead. They involve significant changes to business processes and technology, as well as altering what people do on a day-to-day basis. In addition, there are many project and team members involved with multiple, parallel tracks of work. All of this makes a project manager feel as small as the tiny people in Gulliver’s Travels.
Transformation programs pushed me to think and engage externally beyond my assigned project, especially when it came to dependencies between projects. I also realized it was essential that project managers collaborate and cooperate in order to maintain progress for the overall transformation program.
2. Technology Is in Everything
Over the years, I have followed with great interest the increase in the proportion of a project that involves technology. On my first projects many years ago, the level of technology was quite modest, relying mostly on data inputs, online screens and reports that augmented existing business processes. Today, technology permeates nearly all facets of a project.
When asked to assist with the estimation and implementation of a new type of airliner, my initial assumption was that there would be some form of enabling technology and the airliner would still operate as before. For example, there would be some technology support required, but the fundamental functions would not really change.
After reviews and discussions, I was astounded at the depth of technology that was found in this new model. The flight deck had provisions for laptops to be used by pilots to both prepare and operate the airliner. Flight operations and integration tasks that were once managed manually were now conducted automatically and at high speed, all of which reduced pilot and ground crew workloads. The technology found in this new airliner caused me to dramatically re-think the level of rigor required to estimate and plan its implementation. In addition, it raised my expectations of the effort required to estimate and plan today’s projects in order to ensure quality delivery.
As we consistently execute project delivery over and over across a number of projects, our growing confidence can sometimes cause us to view project delivery as commonplace. We can begin to lose our sensitivity towards project outcomes as we proceed through a seemingly endless stream of phases, sprints, tasks, activities and artifacts of project management.
A big wake-up call for me occurred when I led a project to process calls from customers of infant nutritional products. Customers would call in on a variety of topics ranging from inquiries about the right product to use as well as potential infant health issues. Before I formally began the project, the sponsor reviewed with me existing customer cases showing both simple inquiries as well as potential emergency health issues. I realized then that my efforts on this project could potentially save the life of an infant.
It’s easy to think about projects as two-dimensional entities that refine business processes and technical capability. From the dialogue with the project sponsor, I came to appreciate how this project could improve both the time and quality of response on an inquiry related to the health of an infant. This motivated me and the team to always be thinking about how this project would interact with the customers in the most effective and efficient manner, especially when the life of an infant could be at stake.
As we all proceed through our project management careers, we tend to remember the distinct impact these projects had on us. Some of the projects affect how we plan projects, others influence project execution and still others will be remembered for how they served as key waypoints in our project management journey. In addition, these “waypoint” projects are well-suited as experiences to share with the next generation of project managers following in our footsteps.
What projects on your project management journey have shaped who you are today?
By Conrado Morlan
I’ve been running for eight-plus years—ever since my son suggested I do a half marathon in San Antonio, Texas, USA. So when a friend suggested I try a triathlon, I was ready for it. At that point, three years ago, I had 10 full marathons and 15 half marathons under my belt.
The triathlon includes three disciplines in a single event: swimming, cycling and running. It was the athletic challenge I needed, similar to the professional challenge I encountered when I moved across industries to keep leading and managing projects.
To get ready for the triathlon, I had to go back to the pool and start swimming after a long time away. I borrowed a road bike from a friend to start the formal training. We worked out on our own on weekdays and as a team on weekends.
That first experience transformed me into a triathlete enthusiast, which led me eventually to the Ironman 70.3. The "70.3" refers to the total distance in miles covered in the race, consisting of a 1.2-mile swim, a 56-mile bike ride, and a 13.1-mile run.
The short distance triathlons helped prepare me for the Ironman 70.3. And as I’ve come to realize, learnings I’ve made along the way also apply to project management. These are my three main findings:
1. Expertise and Experimentation
Mastering all three disciplines in a triathlon can be difficult. My background is in running, but I was new to swimming and cycling. My coach gave good tips and workouts that helped me manage my bicycle on hills, navigate sharp turns and use all of my leg muscles to have a better stroke.
For swimming, I followed my instinct and experimented with the breaststroke. I soon felt confident in the pool and gradually in open waters. My experiment worked out, as I finished my swim in the Ironman 70.3 about 20 minutes ahead of the cut-off time.
As a project management practitioner, you may have mastered an industry-standard methodology and need to catch up with the new trends. In the triathlon, you may not transfer skills from swimming to cycling or running, but in project management, you can.
Communication, time management, and people management are required regardless of the methodology or best practice that will be used in the project. This gives you room to experiment. At project checkpoints, you can inspect, adapt and make the required changes to improve your project and be successful.
2. Transition Is Key
The transition is where the triathlete moves from one discipline to another, changing equipment. The area should be prepared in advance, with the gear set up in a way that helps the athlete have a smooth and fast transition. The time spent there may define the winner of the competition.
I would compare the transition area with the risk registry. The more prepared the project manager is, the less impact there will be to the project. The “gear” in your risk register will include the most impacting risk(s), the risk owner and the actions required to mitigate the risk if it arises. It’s a working registry, so the project manager should keep adding risks during the project as required.
3. Anybody Can Help You
A triathlon is not a team event, but that does not restrict the triathlete from getting support from others. Before the competition, the athlete may have followed a training plan supported by a coach, they might have been mentored by fellow triathletes and, last but not least, they likely benefited from family support.
It’s common for some triathletes to have a race sherpa on the competition day. The athlete and sherpa will discuss beforehand what tasks each will take on during the race. In short, a race sherpa will lend a hand whenever necessary and cheer for the athlete during the competition.
As a project manager, you have your project team, stakeholders and sponsor(s), but that does not restrict you from getting help from people outside the project. You may have an internal or external mentor, somebody in your organization who can be influential and help you address issues. I used to have a list of people in the organization I contacted in advance. I let them know about the project and asked them if I could ask for support if needed. That simple action helped me on several occasions when I faced a challenge.
If you are an athlete and a project manager, what lessons have you learned from practicing your favorite sport? Please share your thoughts below.
By Conrado Morlan
“Hybrid” is commonly used in biology to designate the offspring of two plants or animals of different species or varieties. For example, a mule is the hybrid of a donkey and a horse.
But the word has also been adopted in different contexts. Perhaps when you hear “hybrid,” the first thought that comes to your mind is a hybrid vehicle, which relies on two or more distinct types of power to stay in motion.
The world of project management has its own hybrids. New delivery approaches, frameworks and skills can come together in a hybrid form to create something different and valuable.
In different project management forums, I’ve recently participated in discussions about the hybrid project manager. Some proponents were concerned with the technical side of project management, focusing on which method or approach—such as waterfall (predictive) or agile—is better. Others interpreted hybrid as bringing together the best of two worlds to provide results for the organization.
Here are my takeaways from those discussions.
Some project management practitioners think about the profession in purely technical terms. They have devoted themselves to learning new methods, best practices and frameworks that they consider innovative, trendy and useful to support the needs of the projects in their organization.
But some project managers who approach their work in this way tend to think that the method, best practice or framework they most recently mastered is a "silver bullet," pushing previous knowledge they acquired into obsolescence.
Just like any other profession, project management is evolving. There is no escaping the fact that today, many organizations see portfolio, program and project management as the way to link projects with their overall strategy.
Therefore, project practitioners need to consider the heterogeneous elements from the business side of the house to better understand the inextricable link between strategy and execution—regardless of the method, practice or framework. This is how they will deliver unparalleled value to the organization.
This type of practitioner is paying more attention to the PMI Talent Triangle® to identify the skills they will need to be a successful hybrid project manager.
The Hybrid Advantage
Organizations with the right mix of hybrid project managers will:
Do you consider yourself a hybrid project manager? If not, would you accept the challenge of becoming one?