A Complete Overview of Project Management In Managed IT

Solutions
NETRIO
Solutions

Managed IT services are essential for the modern organization. As your pace of digital transformation accelerates, your IT infrastructure will grow in both breadth and complexity. It takes a highly skilled team that has expertise in managing complex environments to provide the proactive support model necessary to stay ahead of the demands of the modern workplace.

EXPLORE SOLUTIONS
Managed IT Services

Cybersecurity

Network Operations Center (NOCaaS)

Connectivity

Hardware & Software Procurement

Voice Solutions
Are Managed Services a Good Fit For Your Organization?

We manage IT and technology assets to free up valuable internal resources to lead and deliver on strategic initiatives that advance business goals.

LEARN MORE
Partners
- White Label Partners
- Channel Partners
Why NETRIO?
Resources
Contact
Book a Consultation
214-888-8500

By: Brian DeVault

Managing a project without a detailed project plan is nearly impossible. That is why NETRIO has compiled a complete list of steps you need to take when creating a project plan that covers every step of the process in detail to ensure that your project has the greatest chances for success. Read on to learn how to create a great project plan from beginning to end.

View Video Transcript

Mike Cromwell

So, Brian, we talked about how regardless of whether it’s a simple project that you’re deploying or a super complex one, that there’s some commonality in specifically 8 key tenets or components of a really good project management plan.

Brian DeVault

All right. So the first tenet of good project management is project initiation. We want to establish what our overall goals are. So the next piece of it we’re going to want to establish is the scope of the project. What all is included in this project from start to finish?

Brian DeVault

So if we think about in some cases, these are assets, in some cases this is technology in general. In some cases it might be subscriptions to Internet service provider circuits. One of the other items that we’re going to include deliverables. So sometimes these can be considered like outcomes. Say I’m merging two enterprise networks into one, my deliverable will be a single functional network that was previously, you know, two separate or segregated networks.

Brian DeVault

The next item we’ll talk about is roles and responsibilities. You may not have named people you can put on those. You just know you need a resource to do X or Y. So the next thing we’re going to want to define is an initial project schedule. And essentially what you’re doing here is you’re putting some some kind of loose start and end dates around it. But based on the complexity of the project, based on the client’s preparedness for the transition, based on the amount of documentation available, based on the condition of the of the environment, all those things are going to have some impact. But that impact is only going to expand our scope by a couple of weeks.

Brian DeVault

So the next thing we want to talk about is the project charter. So what a charter does is defines why it’s about summarizing with at why.

Mike Cromwell

Now we’re going into the second part. So walk us through the components of planning the project and why that’s important as a foundational part of the project management plan.

Brian DeVault

So like you said, after the project initiation, we’re going to go into the phase where we’re planning the project. And so I’ve got some steps up here that we’ve written down that talk through how we handle the process. So the first step in planning the project is refining the scope. So this is where we’re really digging into the details. We’re having detail oriented conversations with the client about what the project is set out to accomplish. We’re talking numbers of devices, assets, people, you know, technology, whether that’s software as a service or on premise technology. All of those things are being defined.

Brian DeVault

We’re moving on to team selection. And here we’re not just talking about resources like an engineer here or a design build architect here. What we’re talking about are named resources. So we’re putting we’re assigning names into the pool. These are the specific people we’re going to use during the duration of the project.

Brian DeVault

And we talk about resourcing. OK, so this is who how many, when and where, who are the people we’re going to need what are the materials we’re going to need? Are there dependencies like such as hardware being delivered?

Brian DeVault

Looking at the project budgets, now we’re we’re putting another level of detail in. So we had a budget established during project initiation. Now we’re really putting some detail behind that and then going into a detailed timeline. So now we’re putting dates down, says we’re going to be finished with the first set of tasks on Wednesday and then the next set on Friday. And we’re really getting that schedule dialed into a day by day granular basis.

Brian DeVault

We’re starting to conduct some risk analysis. So as we drive the detail into that project, it’s going to allow us to see, OK, we’ve got a lot going on in week two and going into week three. So we know there’s inherently more risk involved there. And then finally putting that quality assurance plan in place. So things like performance to budget reports, performance to timeline report, those are examples of QA activities.

Brian DeVault

So once the project starts, you know, we’re managing people largely. And so we’re doing things like schedule performance. So we’re looking at it on a daily basis to say here’s what we plan to have done by this point in time and here’s what we’ve actually done.

Brian DeVault

You’re conducting weekly meetings, maybe even bi weekly, depending on how frequently you need to communicate with the project team. And then we’re providing status updates to project sponsors and to the the project team.

Brian DeVault

When we say resources, the first thing we think about is people. And that’s certainly one aspect of it. But it could be systems. It could be processes. It could be facilities. We’re reviewing our performance to date and we’re determining if we have an adequate amount of resources in order to finish the project on time and on budget.

Brian DeVault

You know, really, when we start to measure activity against the project, we’re talking about what the level of activity that’s that’s being done. Right. So in the in the middle of a project, the activity level is going to be very high. Right. And the level of engagement, the number of people that are involved is going to be very high. And in that case, we’re looking at performance to budget because those people have an hourly cost. Right. In some cases, that’s something we’re trying to manage against. Right.

Brian DeVault

But we also want to look at performance to schedule, as you and I have talked about a lot. The difference between importance and urgency comes into play here a lot, so our performance schedule may be more important than our performance to budget.

Brian DeVault

And really what we’re talking about is adding, removing or changing people, process or assets involved in that resource pool. So one of the things you want to make sure that you do as part of your project planning is set a schedule up front for what documentation you’re going to produce, who it’s going to and at what frequency you’re going to produce it. This kind of sets the stage and sets everyone’s expectation for what they should receive throughout the course of the project execution.

Brian DeVault

An example is a project plan. An example is a performance report. We talked last episode about performance to budget versus performance to schedule. So those can be different things. It should be template based. So any of these documents that you produce should be based on a template so that they’re standardized.

Brian DeVault

And then producing the meeting status report. Any time you hold a meeting, when you’re conducting a project or executing a project, you have notes and deliverables and changes and discussion points that come out of those project meetings. And if you’re not memorializing those in a status report of some type, they basically didn’t happen.

Brian DeVault

In depth about risk management. There’s a lot of different ways and a lot that goes into risk management. Tasks. Each task has a dependency. So in a lot of times you have to perform them in order. And if you if you have a task that is falling behind schedule, then that introduces risk for the tasks that are subsequent. And so that’s where you have to to kind of measure the risk and then add, remove or adjust resourcing.

Mike Cromwell

But obviously, sometimes you have to adjust your timeline also when risk is introduced, just so you’re meeting expectations of all the stakeholders and then you can finish on time. And then also you’ve got your your budget can be in jeopardy. And so by applying resource leveling, by applying communication, by applying some of our previously discussed tenets of project management, you inherently can can reduce the risk associated with not completing on time or not completing on budget or not meeting expectations.

Brian DeVault

The formal methods of Communications communications the PSRs, project status reports, project plans, Gannt charts, those things are absolutely critical to keeping the project on schedule, on budget and successful. And so they have to exist in any successful project management program. And so I find myself having a lot of informal conversations, as well as verbal conversations, even text. You know, I mean, we interact as a team some times with text thread, but definitely stick to your formal reports and in the schedule that you defined up front, create those standards in the form of templates. Right. So the reusable products that you could people understand how to consume and digest. And then obviously these this stuff is going to be reusable in our next phase, which is turnover to long term support. And so we want to make sure that any documentation we’re producing as we’re designing building architecture is like a house. You start with a blueprint and then the blueprint becomes your reference once the the house is built.

Brian DeVault

All right. So basically, this is the part where we’re transitioning from the project team to the operations team or the people that are actually going to deliver the service. Right. So from a project perspective, we’ve got to make sure that we’ve got a few things established. So we’ve got to make sure No. One, that the client knows how to request support. What does that process like? Is it Web based? Is it email based? Is it telephone based? Is it all of the above? They need to know all of those things. So the data has to coincide with the communication about how to request support.

Brian DeVault

Right. So if you’re sending out a company wide communication or distribution that says, hey, on Friday at five o’clock, we’re going to transition to a new support organization, here’s how you contact them. Make sense. So one of the other things we’re going to want to do is review our weekly monthly meeting requirements, so who’s going to continue to meet once we enter the long term support? And what’s that frequency?

Brian DeVault

So we’re definitely going to want to review the long term reporting requirement. So anything like performance to SLA reports, anything that’s automatically produced, we’re going to want to establish that figure out who’s going to receive that from the client’s perspective. And then we’re going to want to review any regularly occurring procedures. So anything that happens frequently, like onboardings and offboardings of end users is a good example that.

Project Initiation – Starting At The Beginning

Before beginning any project it is critical to understand what the company wants to achieve with the project. Whether it is merging two enterprises together, deploying a new service or product, switching to a new business technology, or any other project, you need to understand what the goals of the project are. That is why step one for any project is to clearly define the goals you hope to achieve at the completion of the project.

The second thing you need to do is set a scope for the project to ensure you are laser focused on the goals you defined in the last step. You will also need to define deliverables to make sure your team understands what it is that the project will be delivering. Ensuring that everyone involved understands exactly what the project will be accomplishing is vital to ensure the project stays on budget and schedule.

Next, you will need to define the roles and responsibilities for the players involved in the project and create an initial project schedule with realistic timelines and goals for the individual players in the project, as well as the project as a whole. The final step of the project initiation phase is to create a project charter that contains all of the information previously discussed to ensure everyone is on the same page right from the start.

Planning The Project

After your project charter is completed, it is time to begin the formal planning phase of the project. This will include refining the initial scope that you created in the project initialization phase, selecting the actual people who will be responsible for different aspects of the project, allocating budgets and resources to different parts of the project, creating a details timeline for different stages of the project, analyzing risk at different stages of the project to discover issues that may derail the project and putting a stop to them in advance, and creating quality assurance processes to ensure that the project deliverables are up to standard at every step of the way.

Project Execution

With your project plan completed it is now time for the project to begin in earnest. Your teams will begin to work on their individual tasks and deliverables and your job is to stay on top of every aspect of the project to ensure things are staying on schedule and on budget.

The first step in project execution is people management. Are your team members performing at an acceptable level and getting their tasks done on time? Are certain members of your team taking up too much time or pulling other team members off their tasks to get help? When a certain person or group of people are consistently becoming a problem that derails the project, it is your job to raise the alarm and make a change before the whole project is a failure.

Next, you need to measure if the project is moving at the right scheduled pace. Is your team hitting your deadlines, or do you need to adjust your timelines to be more realistic? Next, you need to establish and maintain weekly (or whatever cadence is appropriate for the project) meetings to check in on different teams’ progress. Finally, you need to communicate updates from these meetings with the appropriate stakeholders to ensure everyone is on the same page at every stage of the project.

Resource Leveling & Control

In nearly every project there are phases where activity is higher or lower and adjustments need to be made to ensure the appropriate amount of resources are being allocated in the right areas. At every phase of the project you should be measuring activity. How many people and hours are needed to accomplish a specific task at a specific time? Are there too many or too few people working on a task? How important are the different tasks that are ongoing at this time? All of these questions need to be taken into consideration at each phase of the project.

Next, you need to review your team’s performance to budget and performance to schedule. Are you going over or under budget at any phase of the project? Are you ahead or behind schedule at any phase of the project? All of these things need to be accurately assessed at each stage of the process before any intelligent decisions can be made regarding changes to resources.

Once you have a clear picture of the project and its different parts at the current time, you need to make changes to your team’s players or focus, whether that means adding new team members to different tasks, switching team members from one area of focus to another, removing team members, or providing new tools to get the job done, this all needs to be done often and with as much accuracy as possible to ensure your team is being as productive as possible.

Documentation & Risk Management

Near the beginning of the project you should create a schedule of documents that will need to be created, such as project updates and performance reports that can be communicated with your team and the project stakeholders to ensure everyone is in the loop on the status of the project and to ensure no stone is left unturned during the process. These documents should be templatized as much as possible to ensure you are not spending excess time on writing documentation versus actually managing the project.

You also should be assessing risk with each task and phase of the project to ensure nothing has the possibility of derailing the project. Examples of things that can derail a project include key team players leaving the company, going over budget, changes to the project plan from upper management, the wrong team members being assigned to specific tasks, and anything else that can unexpectedly cause the project to come to a screeching halt. You must be keenly aware of these possibilities and have back up plans in place should any of these possibilities come to pass.

Communication & Handoff To Long Term Support

Throughout the entire lifecycle of the project you will be required to communicate with team members and stakeholders. Communication can take two different forms: formal and informal. Formal communication can include things like Project Status Reports or Gantt charts that are sent through official channels to a wider audience and informal communication includes in-person conversations, emails, text messages, or any other faster and usually smaller circle of communication. You should have document standards in place that are templatized to speed up these types of communications to ensure you are not spending a large amount of your time creating the same types of documents or typing redundant emails again and again.

Finally, after the project has been completed, the final step is to hand off the project to long term support. Once the project is completed and handed off, you should communicate with stakeholders how they can request support, whether that is through email, telephone, or some other channel, as well as ensuring that dates are clearly defined for things like reviews and checkups. Next, you will want to review weekly, monthly, and long term meeting and reporting requirements as well as regularly occurring procedures (like onboarding and offboarding, etc.) to ensure everyone is satisfied with the project and that it will continue to be successful long after project completion.

This concludes our overview of the lifecycle of a project. We hope that this has been helpful for you when creating and managing your project. This blog post is part of NETRIO’s weekly Whiteboard Wednesday series. Follow along on Linkedin and YouTube each week as Brian and Mike discuss use cases, new technology, and trends.

NETRIO
Solutions

Are Managed Services a Good Fit For Your Organization?