How to Adapt Your Project Management to Different Projects

Trevor Methena
Looped In
5 min readMay 13, 2016

--

In project management, most practices stay the same no matter what type of project you’re working on. You take a logical start-to-finish approach towards completing a project: a new marketing campaign, a specific piece of software, or installing an entire IT infrastructure inside a new building. Within that approach, there will be subtle nuances based on type, scope, and breadth of project.

The Big Picture

I am a huge proponent of ALWAYS taking a lean approach to a project. Trim the excess processes that are not applicable, stay agile, and don’t waste time and money. This will provide your clients with a better return on their investment in you. Making your clients happy will keep them coming back for more projects and products, allowing both parties to grow. This is sometimes overlooked from a project management perspective because project managers (PM’s) typically don’t start talking to the client until late in the sales process. As a PM, it is essential to keep your clients happy because this allows companies to grow. It’s just that simple! Here at Metric Loop, we involve our PM’s near the beginning of our sales process in order to establish an early relationship. It is essential to create a rapport that is focused on using all the knowledge and tools available to ensure that the customer’s needs are being met during the process of the project.

Within the role of a PM, one also must be able to discern immediate needs as well as anticipate future needs of a customer. In addition to building a timeline, setting goals and expectations, and organizing the implementation strategy, a PM must work closely with his or her engineering team to provide a solution that can not only efficiently resolve an issue, but also have the ability to scale according to the company’s growth trajectory. A high level view at the beginning of any project is a simple way to design a logical plan that can result into a productive working relationship between all parties involved. Within each step of the project, a PM is responsible for consistent and competent service and a direct line of communication between your engineers and customer. This allows the high level view to be executed in a seamless and timely manner.

Software vs. Infrastructure

Within the technology industry there are indeed differences between the types of projects presented. So what are the differences between Software and Infrastructure project management? Let’s dive into some of the small differences while keeping in mind that the same PM should have the requisite skills to perform both seamlessly. The largest differences between the two types of projects is how you section the project off into smaller more manageable “bites”.

In software one of the best practices I have found is to section off the project into “versions” or small subsets of the project. Some of you may know this as Scrum. Scrum takes a software project, budget and timeline then breaks it up into smaller micro-projects or sprints. This allows the team to work in a focused approach with shorter end goals that can be shipped right away. If the product isn’t ready to be shipped by the end of the sprint, then the process is tweaked and the team starts over. This iterative process allows the team to continually re-evaluate their work to stay agile, focused, and on-budget as they determine the next immediate course of action. One thing that is inevitable when developing software is the introduction of bugs, or uncaught errors, in the application. These are caused by a number of factors and are not indicative of poor system design or incompetent developers (though they should be taken seriously). So, when breaking the project down into sprints, the best thing to do is always revisit your unsquashed bugs list. Incorporate bug-fixes and new features into your next sprint and deploy to ensure that your level of technical debt remains low.

With hardware and infrastructure, some people claim Scrum can also be used. I, however, do not feel the same way. With an infrastructure project, especially on a large scale, it is important to utilize everyone’s expertise in order to not waste time and money. I’ve found that breaking a project up into increments based on task type, as opposed to mixed groupings like a Scrum approach, leads to better results. This approach forces PM’s to pay close attention to the schedule, and helps to minimize installation times for each section thereby saving money. A tactic to consider with any size project is to reverse-engineer your project’s schedule based on your deadlines. In doing so, it always important to leave as much flexibility in the schedule as possible and make sure you leave plenty of padding for unexpected events. Additionally, communicate with your teams to make sure that they can work without overlapping with other teams on the schedule. Is your back end installation team able to be on site installing racks and switches prior to cabling being completed? How far out can they start? Will there be room for multiple teams to work simultaneously? Ask these questions at the beginning and stay on top of it throughout the life of the project.

One last consideration for both types of projects is to have the project manager take a step back and identify how they should engage with each teammate’s style. Let’s face it, software engineering and IT infrastructure are industry specializations that attract vastly different personality types. Don’t take a cookie cutter approach of engagement with your teams and you won’t have a cookie cutter outcome to your project!

While the core principles of project management stay pretty consistent between different types of projects, there will always be some variations that depend on what you’re trying to accomplish. In the software world, it’s often easier to organize your projects into sprints that deliver bite-sized snippets of functionality. But in IT Infrastructure the realities of tangible hardware and labor calls for a more step-by-step approach. In either case, it’ll be up to you to determine the appropriate process and style that will yield the best results for the project at hand.

Originally published at metricloop.com on May 13, 2016.

--

--