Project Management is the emerging science that enables people, systems and technology to participate and create new and amazing things
The definition of science is:
“The intellectual and practical activity encompassing the systematic study of the structure and behaviour of the physical and natural world through observation and experiment”
Beginning something with the end in mind, is one of the pillars of civilization, and the ability that mankind has developed in order to go from 0 to 100 into project like the great pyramids or the first internet is a testament of how important project management is.
History of PM in two paragraphs
The first basis for project completion is to have an idea, arrange the required resources (material, knowledge, people, money) and move forward until the initial idea is complete
The second basis of project completion comes from the realization that resources are not infinite and efficiency and efficacy are very different things, and accomplishing something with the least amount of resources is actual management.
Current State of Project Management
Currently every project falls under the umbrella of a specific framework and set of rules that has to be followed in order for succeed in the project.
Every project manager has the responsibility to understand the project needs and apply the most suitable framework to the project, in other cases, the project is created to be used with a specific framework (this is not the ideal scenario).
The worst case scenario is a project with no project management methodology at all.
Good practices dictate that the project manager needs to be certificated in a specific methodology or institution such as PMI, Scrum and others, with the idea in mind of the PM to be a specialist in that specific methodology.
Having a specialist and that being the current trend, by the hand of the project manager, the stakeholders, execution team and other key players will go by the book in each one of the steps or requirements of the methodology.
Type of Project Management (Quickly)
Before going deep into a hybrid approach, is key to learn that there are big groups where each PM can fall into, the first one being:
- This type of methodology is very useful when the initial parameters of the projects are known and solid, such as scope, requirements and possible minimal risks, especially regarding change.
Adaptive / Iterative and Incremental
- The scope, requirements and some project variables are expected to change as the project requires flexibility for it to “adapt” during the execution”. The scope also evolves but is expected to have deliveries in smaller “chunks” of time.
The most known frameworks fall into each one of these buckets, being waterfall, scrum, Kanban, XP and others.
The best example of a predictive approach is the waterfall method, mainly because it is sequential, has little margin of error and easy to report to management. Each one of the documents and phases are very well documented and has a long time experience in project management for it’s execution.
The best example of an adaptive / iterative and incremental approach is scrum or agile methodologies, where their process is more flexible, change is expected and the documentation is less defined. As this methodology is flexible, it relies on the cooperation of the entire team, from management to execution and apply the required “ritual” to comply with the process.
Hybrid Project Management
One thing that we have learned through many projects, and to be honest the amount of projects that actually fail is that there is no magical framework to guarantee the success of the project.
What is true, is that project management, especially good project management, has a lot to do if a project is successful or mid-successful or a complete failure.
The idea of Hybrid Project Management is to have a good knowledge of as many frameworks as possible or some of the artifacts of each methodology in order to create a HYBRID approach and create a tailored Project Management Methodology for what the project needs.
The mantra for Hybrid Project Management is:
“Ultimately, just use and do what works for the project”
One thing that is very important to this approach, is that in order to have a tailored methodology to the project, there has to be a good understanding of what each part and artifact of each methodology is intended to do.
Even though doing a hybrid methodology may be considered to be the hardest approach to project management because it involves having more experience, it actually increases the possibility of project success.
This creates the need of experienced, educated, creative and versatile project managers that are laying the future of a science that began being really squared and is becoming a huge area of expertise.
The above image is intended to simplify the high level stages of a project
A small example of how hybrid works
Life Cycle Approach
The lifecycle of a project is the exact process that takes the entire team to generate value to the expected outcome for the project.
The main difference between the types of cycles if the delivery cadence, that is how much time it pases between deliveries.
Final value cycle:
One of the most common methodologies and oldest ones that is documented is waterfall, and is commonly associated to deliver the final value or product at the end of the lifecycle of the team’s work.
This reduces the amount of time spended in product presentations, reduces the amount of involvement of the stakeholder and management team in the day to day operations and generates an end focus goal to the team.
This type of cycle is typical for a predictive approach.
Iterative value cycle:
This approach is focused on dividing the project into smaller deliveries and showing value to the end users or stakeholders as each part of the project is ready.
This approach needs constant involvement of key people of the project, such as product owner, stakeholders and even project sponsors.
The idea of this iterative approach is to showcase continuous progress and have continuous feedback from the end user.
Minimal Viable Product is a mix of the previous both approaches. The idea is to create an end product but with the idea that it is not a finished product.
The team speeds up the process, reduces the details and creates a rough version of what is supposed to be the end product.
Then it is presented to the interested parties of the product for feedback.
The MVP is now in an iterative process of finished products until it fulfills all the requirements needed from it.
Analysis — Design
Every project starts with a requirement, a necessity to be filled and based on that, start an enterprise to fulfill that necessity.
This document states the scope of the project, the final state of what is the outcome required in order to mark the project as completed.
The idea behind a vision statement is to be the anchor to start a strategic planning, it does not require to have set in stone scope, requirements, costs and other items that a predictive methodology requires.
This is very useful for projects that are more focused on creativity, that do not have an established roadmap for the beginning but require to have a document to kick off the efforts.
There is no structure or lineaments of how the document should be, so it’s up to the project manager to make the best outcome for the project.
For an adaptive project this document is enough to start working in the project
This document is a more structured and managerial document.
One of the biggest changes from a vision statement is that this is most commonly created by a project sponsor or a key stakeholder, it’s a more structured document that validates and gives the green light to the project.
It contains key information such as the official project name, who is authorizing the project kick off, project governance, business case, budget, risks and other key elements that the creator of the document may consider necessary.
You may find many templates for project charters and this are meant to be signed by the key people in the project.
SMART Objectives and OKRs
Is key that in the project beginning some objectives are layout so the scope is not far ahead of the mindset of the team.
Talking about the difference between SMART Objectives and OKRs are beyond the scope of this writing, but I think it is very important and a key addition to Hybrid Project Management.
Creating the roadmap
All projects require a future in sight of activities to perform in order to start working.
How far these activities or how detailed is what makes the difference between each approach.
One important thing to take into account is that the roadmap is meant to clearly represent the project lifecycle.
Even on a hybrid approach there are common items that are advisable to represent in the roadmap, and those are:
These represent each big step in the project, it may show the documentation phase if you have a predictive approach, or show an iteration in an adaptive approach, the goal here is to divide the project into clear buckets of efforts in which we can place specific work.
Is important to the team and the project governance to have a clear knowledge of each “big thing” and it’s the best way to measure progress at a high level.
This type of “moment” in the roadmap is more common for predictive approaches, however it can also apply inside an iteration or a complete adaptativo project.
This is nothing else than a delivery that allows the project to move forward to every other aspect inside the “big buckets” of project management.
If this is not completed, then it is a blocker and the project is on hold until it is completed.
In agile projects this is also known as readiness review.
Inside the roadmap there are important items to deliver, steps to accomplish or products to present. This are known as milestones, they work to know when something important in the project has been achieved and normally in represent the ending of a particular effort by the team
Even if you did not set OKR inside your project, you can represent into the roadmap the expected deliveries you will present to each end user. Even the deliverable can be specific to a targeted audience and not the entire project governance. The main intention here is to know when something is due, why and who is going to validate it.
The most important, tasks
From the scope of the project, a project manager needs to create tasks for the team and in the completion of them, the objective of the project is met.
There are two main ways on how to state an scope:
This type of scope is closer to an adaptive approach, since its main goals are to have clear deliverables, features and functions.
The task can be broken down with that.
On the other side, on a predictive approach, you specify in the scope the requirements gathering, development, testing, documentation, reporting and any compliance if it applies.
Either if you chose each one of this scopes the next task is probably one of the most important and that will require the focus of the team, project manager, product manager and even stakeholders.
Breaking down tasks:
It’s all about organizing work, it does not matter how
The two most common approaches to beak down tasks systematically are WBS and Backlog. Is important to state that both are not one or the other, both can be used in the same project.
Work Breakdown Structure
It’s a simple to the eye easy to use tool, since in it’s core is nothing more than a diagram, but being well done is the task and priority map that a project needs.
The following is a simple example of how it can look like.
A WBS main characteristic is its levels, in this case we’ll take the WBS in the image as an example.
The scope of the goal for the project is to have a Snack in the Living room, every work that is done in the project should be with that idea in mind.
In a second level, the project is broken down into three main categories, and in a third level a more precise approach on what are the tasks needed to perform.
There is no exact rule on how many levels a WBS should have, and not every branch should have the same amount of levels.
The important outcome here is that each task that can be broken down into smaller, more manageable tasks is represented in the diagram, and at the end, the last level of each one of the branches are the tasks needed to perform in the project.
Backlog and User Stories:
This is required for almost adaptive technologies, because it works based on simplicity and completeness on all the tasks needed in the project.
The backlog is usually formed by user stories, but it can also be “translated” from User language into Team Language, this is because a user story is written in such a way that a person that is not technical or not familiar on how to produce the outcome needed in the project, can state its requirements.
A user story covers The Who, what and why of a necessity and generally has this structure: As a ___, I want ___ so I can___.
The project backlog contains all user stories or all requirements for the project, inside the backlog the organization can be grouped by type of user stories into epics, sprints and other types of work breakdown buckets.
Priority or weight on tasks:
This idea is mainly used in adaptive projects, but it can also be applied for predictive projects.
The main goal here is to establish a “metric” system to weigh priority and technical difficulty in each one of the tasks.
This part of task management is really important, because it produces very important information such as the critical path, and can make you take decisions on what to work first in case of an urgent delivery or also what can be worked in parallel in case of a delay in the scheduled delivery.
Task should have an importance inside the project and an assigned difficulty.
Scheduling everything inside a project
One of the key activities of project management is to schedule the work in the most efficient and effective way.
The main goals for scheduling are the following:
- Tasks are well organized and do not produce bottlenecks
- Each task is assigned to the best suitable resource
- The resources are working at their best capacity
- The timeline of the project matches the one that was set at the beginning of the project
There are tools that help the PM to make this process systematic.
This is a very basic representation for scheduling work, and is based on the idea of a well organized set of tasks into buckets of work.
The order in which each bucket needs to be done is reflected by a relation between items in the diagram.
How the items are placed is important, since it’s a visual representation of the start and expected end time for each block of work.
Also the relations can mark if an item can only begin after the previous one has started, if some items can be worked in parallel or even if one can start at the middle of the other can.
This type of chart is probably one of the most common representations of the relationship between tasks and time.
This type of tool is more common for predictive approaches, but it can be fitted into an adaptive framework.
The idea of this type of chart is to represent text and in a graphic, the levels, time boxing, relationships, constraints, milestones and resources allocated for the project.
Taking a hybrid approach, a Gantt Chart can be used for the project, por an epic or even for an iteration or sprint.
It is expected that each time box has a release, product or milestone at the end.
KanBan Board and Flow Scheduling:
The KanBan board is a technique that is used in lean manufacturing to represent the flow of work inside a value stream.
In this case, each column represents a box of work that needs to be performed inside the project.
Inside each of the columns there are tasks, user stories or the minimum entity defined to structure work.
The idea is to place at the beginning of the board the tasks that need to be performed, as as long as the transition through all the phases in the project, they are moved horizontally into the board.
You can say that you have finished when you have successfully moved everything from the start column to the end column.
Iteration and releases
At the end, the idea for scheduling inside a project is to break down the tasks into the best approach on how to finish them.
Either is using one of the methodologies above, a combination of them or a different technique that works, the idea is to organize into a timebox each block of work, assign them a value in terms of time or “weight” and proceed.
There is no magic recipe for one fits all, the main goal again for this is to organize and optimize resources.
Estimating work is one of the hardest parts of project management, because there is always the fear of not getting it right, and particularly to undervalue how complicated some part of the project might be and in the long run it will cost the team a delay into what is expected.
However hard the task is, it has to be done, because as a project manager you must at least have a grasp how much it would take the team to finish a time box of work.
In order to solve this problem, there are a few techniques out there that can be useful when estimating the work is key.
This is the most common in every day project, and that is to assign a value that makes sense to the team.
This is a very good example on how predictive and adaptive approaches share the same need but the solution may be different.
In this approach you may assign values such as easy, medium or hard.
Also assigning hours, minutes, days or any measure of time is valid.
In agile is common to use story points
You can get creative and use the size of clothes, S, M, L, XL, or any grouping that the team can find relatable and can be assigned to each one of the tasks.
WideBand Delphi and Fibonacci estimating:
The idea of WideBand Delphi estimation comes from the 1950–1960, but is still valid today.
Someone in the team, usually the project manager or project lead presents to the team a task, user story or one task that needs to be estimated.
The task at hand gets explained by the documentation and knowledge the expert has on the task, then the team makes questions that are relevant for assigning value to the task.
Once the entire process is complete and no more questions are added then each one of the team members assign the value they think the task is worth.
Here is where the Fibonacci estimating enters, the Fibonacci sequence is starts with the numbers 0,1, and then continues by adding the two previous numbers, for example:
It is commonly used in the WideBand Delphi estimating technique for each one of the members to assign a Fibonacci number for the task.
The process of decision for this has a variety of scenario, from assigning and discussing until reach an agreement, even there is something that is Poker estimating, where as a game of poker, each team member assign the value in a hidden card, and the cards are revealed and they keep serving cards until there is a consensus on how much the task is worth.
This is maybe the most common type of estimating, and is based on experience.
Since each one of the members may have a different perspective on how much a task can be worth, they assign based on their experience in previous projects or similar tasks.
In this type of estimating the rank of who decides the roadmap and timeline is very important.
Most of the time is the Project Manager or Tech Lead who takes the responsibility to assign the weight on each task.
The best approach in this case is to ask the team for their opinion, maybe consult with some expert in the task at hand, but in the end it is a hard estimation based on experience.
Multi Point Estimating:
As mentioned previously, one of the biggest fears at estimating is under-valuing one task, so much that it can break the project timeline.
In this case this technique takes that into account, and by any method agreed (as long as it is numerical), each task is assigned 3 different estimations.
- Worst case scenario (Pessimistic) — everything went wrong
- Most likely scenario (Realistic)
- Best case scenario (Optimistic) — everything went well
After that is stated the the following formula is applied:
[Worst case scenario + (Most Likely * 4) + Best case scenario ] / 3
The result of the formula will give the weight that you must assign to each task.
As with all the other methods and techniques, you should find what works for the project you want to estimate.
Besides the ones that were shown here there are a lot of other techniques that can be applied.
The importance of Team Management
As a project manager, you always need to take into account the project team, and this means that your view needs to be bigger than just the execution team, but also stakeholders, product owner and even suppliers and other people that may be involved in some of the tasks in order to complete the project.
How the team works in a scheme such as waterfall is a little bit more straightforward that other types of team management.
For this type of project it is clear who is the sponsor who funds the project, in other terms the client or the highest authority in terms of project development.
The project manager works with the sponsor in order to present progress, validate deliverables and request help removing blockers and receive change requests.
These types of projects work in a more hierarchical way, where the sponsor is at the top, middle management and execution team is at the bottom.
Reading the top description may make you think that is obvious that the adaptive approach is better, however the adaptive approach requires the involvement and cooperation of more people in order for it to work.
Some of the members of the team are project sponsor, product owner, scrum master, stakeholders, project team and external consultants.
The distinction from project governance and execution team is also present, but the communication, meetings and involvement is highly recommended and even encouraged.
In an adaptive approach the structure is viewed in a more horizontal way, where everyone is a key part of the machine that makes the project work and its work is to facilitate other parts to work.
There are many ways in which a project manager may approach a team inside a project, but this two are the most common.
If I could advise two main ideas on how to manage a team are these:
- Always achieve to make the team work together and facilitate communication and conflict mediation.
- Every team member brings equal value in the day to day execution of the project, if you assign more weight or importance to other members, you may cause a project imbalance.
Meetings — How much is too much?
“If you have to identify, in one word, the reason why the human race has not achieved and never will achieve its full potential, that word would be meetings” .- Dave Barry
There a are a lot of recommendations in terms of meetings, either is it predictive or adaptive project, many meetings are advices to have in a project
- Kick off meetings
- Requirements meetings
- Follow up meetings
- Delivery meetings
- Daily Stand ups
- Planning meetings
- Demo meetings
- Retrospective meetings
- And many more
As a project manager you have to make sure that you are having meetings that bring value to the project.
This means that not all meetings are necessary and on the other hand there are meetings that are a must have.
It depends completely on the project and the needs, there may be projects that require a daily standup each day of the week, there may be other projects that one catchup meeting a week is enough. It all depends on how the PM feels about the project.
Not all is the frequency and duration of the meetings, is also as important that the meeting is effective, and in order to have an effective meeting there a few tips that can be followed:
- Only people relevant to the meeting should be allowed to participate (Other people can attend, but as listeners)
- Having an agenda for the meeting distributed before the meetings is key so everyone knows what the meeting is about. Having a clear objective is key in order to reduce time.
- During the meeting it is important to have a meeting minute in order to know the action items, agreements and people involved.
- There has to be a clear meeting owner or moderator, so e can guide the participants and avoid losing track of what is the objetive of the meetings.
- Once the meeting objetive has been met, then other meetings can be scheduled if other points were raised.
- The meetings should have a block of time established, is not expected to retain the project members for more time that was established.
Meetings are a great tool in order to improve performance, enhance communication and reduce time in more formal communications such as emails or documents.
That is the main reason why the agile manifesto states that human interaction is recommended above documentation.
Project Management is the key factor for many of the current enterprises to go from nothing to complete products or services.
How this project is assembled is under the best knowledge of the leaders that plan the project.
What is true nowadays is to have a certification in just one methodology by no means guarantees the good outcome of the project.
A project manager should have many tools at his disposal and understand what that tools are used for, so we can select the one that best applies to each case.
The last recommendation that I can provide is that for each project, the PM creates a guide on how the management is going to look like and not go step by step along the project.
At the beginning of the project the PM should state the methodology that is going to be followed and make the adjustments to this process along the way.
This document should be shared and known among all the members of the team.