Project Management 101 : How to successfully manage projects?





                                                Photo Credits: photopea.com

As I foray into the field of project management, I've started to notice some common trends in planning and execution strategies. These strategies are the quintessential essence of best practices in managing a project from the hundreds of articles I've scoured through for information, over the past couple of months. This post is intended as a possible framework of operation for anyone new to the project management(PM) role to get a higher likelihood of successfully planned and executed projects.

1. Set the calendar

Before even thinking about what the project is about and how the planning can be executed, the first step would be to set a frame of reference for time! How is the project going to be measured in terms of time? What are the working hours going to be like? Will it be a 24 hr/day, 7 day work-week or will it be the standard 8 hr/day, 5 day work-week with the weekends off? These are some of the questions that are best gotten out of the way before the planning starts. There are two advantages to this. The first one being that having such a frame of reference allows you to make good estimations on time needed for task execution when the project will be scoped and the other being, that it will allow you to understand for yourself, as well as project the correct expectation to the client right from the beginning of the project. Such an understanding can be extremely useful in day 1 hr 1 activities which the author of the book "Day 1, Hour 1" Michael Rice, defines as the "first moment from walking through your customer’s lobby to getting in the conference room and the first interaction". While the physical aspects of this advice may not be valid in the pandemic era, the core principle still remains sound. At a later stage, this calendar will also allow you as the project manager to accommodate any PTOs (Paid Time-off), sick-leaves and public-holidays that may have otherwise had an impact on the project timeline, once the work resources are allocated (more on this later).

2. Penning down the project charter

Imagine this, you've set the calendar, scoped out the project and finalized on the deliverable milestones and are rearing to get started with the project BUT it turns out that the project has not been approved by the leadership in your company? Won't that be all your hard-work for nothing?

In order to avoid such a situation from arising it is extremely important to have the project approved from someone senior enough to sponsor the project in the first place. This is where a project charted comes in handy. A project charter can be thought of as a formal document that officiates the project plan to be set in motion. It is basically a formal document that lists out the project in its entirety including who the stakeholders are, what the scope of the project could be and what the expected deliverables are. This document however is not something to get approved and forget about at the start of the project. As the project progresses, more often than not, there are bound to be some changes in the expectations and scope of the project. The project charter thus needs to be updated throughout the course of the project, to allow for the change requests while at the same time not steering too off-course from your originally chartered plan. Think of it as a living document, that grows and learns new things as the project progresses. A good analogy would be with the flight charter plans that are used for making plane journeys. Before actually flying the plan the source and destination places are decided upon, along with who will be flying the plane and what the general direction the flight is going to be. During the flight however, there can be minor deviations from the chartered flight course due to some turbulence or bad-weather. The end destination remains the same, however the path taken to reach that destination may vary slightly. A project charter is very similar to this, as long as the end goal remains the same, changes in the paths taken to achieve that goal can be accommodated for.

3. Defining the Statement of Work

Once the project charter has been approved the next step would be to get the scope of the project from the client. Depending on the service/product delivery life-cycle being followed at your organization, this first high-level scoping of the project deliverables is defined in a document called the Statement of Work (SoW). The SoW basically breaks down the project revenue into segments, at the end of which a milestone would be reached, where a deliverable has been successfully delivered to the customer and revenue can be recognized. Having such a document is a great way to ensure that client expectations are met while sticking to the project budget. The milestones and deliverables defined in the SoW are typically not changed throughout the course of the project except in the case where an explicit change request has been raised, and the project goals need to be modified to realize the changed goal. Also, it is here where the assumptions necessary for planning a project are discussed beforehand with the customer.

4. Project Planning

This would arguable be one of the most important phases of a project life-cycle. Here's where the entire project is planned out in much detail, right from a high level overview of what milestones and deliverables are key for project and customer success to the most granular level of how much of an individual sub-task has been executed. The SoW acts as a great starting point for deciding on the project plan. The milestones defined in the SoW however need to be broken down into phases, tasks and sub-tasks for work allocation to resources and effective tracking of project progress. There are multiple softwares available to assist project managers in etching out the project plan. Microsoft Project Professional(MPP) and ProjectLibre are two of the most commonly used enterprise and open source project planning software solutions respectively. These softwares allow you to draw a Gantt chart for effective visualization of the project plan. These softwares are in-fact useful throughout the project planning and execution phase right till the end of the project life-cycle and have excellent project support capabilities.

5. Resource Allocation

Now that the project plan is in place, all the phases have been defined with task, sub-tasks, milestones, deliverables and timelines clearly defined, it is time start allocating resources to get these things accomplished. Now there are 3 types of resources commonly in play. Work, cost and material resources. Classifying people as a "resource" is a terminology that I do not endorse, however for the sake of simplicity, we will use the term "human resource" to denote people working in some capacity on the project. Work resources would be the equipment and people or human resources that would work on your project tasks. The defining attribute of this type of work resources would be that these are human beings. Which means each individual would require compensation for the efforts put in and this cost would have to be factored in while deciding on the budget. As a project manager your goal should be to interact with various engineer, subject matter experts (SMEs) and business development managers(BDMs) to understand the scope of the task at hand and decide on realistic timelines to achieve the end goals based on the input and historical empirical data available on the time taken to complete a task. This is why setting the calendar at the start of the project is so important. Once work resources are allocated to a task, it becomes important to factor in all types of possible breaks that might crop in, like upcoming PTOs, planned sick leaves, etc. Having a calendar for reference from the start allows the PM to quickly populate such dates so that the scoped time for the completion of a task coincides with the actual time taken. It is also common to assign tasks to a designation temporarily till the actual resource mapping is done. For instance the development of a product module can be assigned to "engineer 1" and "engineer 2" till the time these roles are mapped to actual people.

The second type of resource is cost resources. These are the costs that are associated with the completion of a task in an indirect manner. An engineer moving to another country for the completion of a task would not just require payment of working hours for the engineer's efforts but also the cost of travel, food and accommodation involved. These additional expenses of taxi, food, and hotel fall under the cost resources category. These would typically be one time costs but can be recurring as well best on the context of the project task.

The third type of resource involved is the material resources. The defining characteristic about this type of resources would be that once consume these resources cannot be reused. These are also typically recurring costs as new resources need to be allocated each time a new need arises. An example would be the licenses used for availing certain features of an on-premise product. One the license duration expires, the same licenses cannot be reused and a new set of licenses would have to be generated.

6. Project Baselining

Once the resource allocation is done, we have a clear plan of what needs to be executed to achieve the targets. However before beginning with the actual execution, a good practice is to baseline the project. A baseline can be thought of as a snapshot of the project status. A good analogy would be of how we take snapshots of the working state of a Virtual Machine (VM). The snapshot will contain all the details of the memory consumed, changes in data made, CPU resource utilization details, etc. A project baseline is exactly the same. It contains all the information like the current start and end date of tasks, what the initial milestones are, and the status of the project tasks at the beginning of the project. The advantage of doing this becomes especially evident at the later stages of a project where multiple change requests have been made. Baselining allows the PM to compare and contrast the changes made from the originally planned values. It also help keep track of how well the project is doing and the variance plots can be a useful metric to showcase to the executive panel interested only in the deviation of the project from the original plan.

7. Project Execution

This would be, the other most important aspect of project management. Now that we have a well detailed, granular plan in place the next step would be executing this plan successfully and meeting the targets and milestones decided upon. Project execution involves executing each task in such a way that the deadlines are met and the project plan is followed proper. As Richard M. Kovacevich, the former CEO of Wells Fargo & Co., quotes "A vision and strategy aren't enough. The long-term key to success is execution. Each day. Every day".

8. Deciding on Critical Path

 The critical path in a project can be defined as the longest duration of a sequence of interdependent tasks which determine the shortest duration in which the project can be completed. Any changes to any of the tasks in the critical task will affect all the subsequent dependent tasks and cause the entire project duration to change. Any easy way to determine the critical path would be to list out all the possible path sequences from start to finish in a linear manner and up the duration of the linked tasks. The critical path would be the path for which the sum of the durations of each of the tasks is the greatest. It is important to keep in mind that any delays in the tasks on the critical path can cause a delay in entire project and hence it is important to ensure that such delays do not creep in on the critical path tasks.

9. Managing Over-allocation

Oftentimes when working on a project with really tight deadlines, some work resources might be over-allocated. Which means that the resource is expected to do more that what is deemed possible based on the work schedule. As a PM, it is important to keep track of such over-allocations when managing a project. There are multiple ways of handling resource over-allocation. The task can be split and assigned to another resources with the available bandwidth, but such a solution would mean incurring the cost of adding another resource to the project. Also, in the case of any dependencies, the next resource cannot start work until the previous person has completed their share of the tasks. Another method would be to utilize the bandwidth of a resource already added to the project but not having any immediate commitments. There are many other ways to manage resource over-allocations which would fall beyond the scope of this post, and at times such over-allocations might even be intentional, but the key takeaway here would be to be aware of them and consciously manage and mitigate the risk that may arise of them.

10. Raising Change requests 

Large projects can often range for over a year or more. In such cases, a client might not always have all the requirements and goals right from the beginning of the project. The clients goals might change with time so much so that they might be very different from what was agreed upon in the project charter or what was finalized on the SoW. In such cases, in order to ensure customer success, there are some changes to be made to the project plan. However it is important to follow a set procedure to make these changes as it would other lead to scope-creep and one may end-up over-delivering while being underpaid for it. In order to avoid such situations a change request can be raised by the customer which will be discussed with all the stakeholders before revising the project charter and the revenue on the deliverable accordingly. This is another important segment where baselining is useful. It allows the PM to evaluate and compare the changes being made.

11. Risk Management

Risk is an intrinsic part of any value generating activity. When a project is underway, a risk can be defined as an event that may lead to potential failure of a task or the project as a whole. There are various types of risks that can be involved in a project as each facet of the project is vulnerable to risk. An example to elucidate what risk can be as follows. Imagine a task of completing a critical module of a software project. What would happen if the person responsible for completing the module quits? What if such thing happens right before a critical deadline? This particular example is that of a resource risk. There are many other types of risk like technical risk, scope-change risk, etc. Thus it is very important for a PM to be cognizant of such risks and to take preemptive measures to mitigate the impact of such risks. For the example at hand, a possible risk mitigation strategy could be to divide the task between multiple resources to reduce the high dependency on a singular resource.

12. Project Reports

Finally, it is just as important to showcase the quality of the project and its execution to all the stakeholders, as it is to execute them successfully. There are various visualization softwares that allow PMs to create well-designed and appealing charts, graphs and dashboards to visualize the project. Microsoft Projects actually allows for a whole host of such data visualization options. Such visual aids are a great way to present complex and convoluted information to the executive panel and the client in a clear and concise manner.

Reactions

Post a Comment

0 Comments