Process vs. Strategy: What does your project use?

Do you like to manage your projects through a procedure or with a strategy? As learned in the PMP Certification course, we’ve even heard these names used interchangeably on occasion. They are not, however, the same.

· A process has a set of steps that must be followed in order to be completed; however, a strategy may not always have the same set of steps.

· A process is always a part of a strategy; a strategy is created to meet the goals of the company.

· Top management authorities may or may not define a method, but top management authorities always create a strategy.

· There are distinct inputs, outputs, tools, and procedures in a process. Plans, procedures, initiatives, tools, and approaches may all be part of a strategy.

As a project manager, I follow the processes that are specific to the project and ensure that the team follows them as well. However, just following the methods does not produce the desired results. As a result, a project manager must design tactics in order to acquire the required outcome from the team.

For example, I was working with a scrum framework organisation where it was required to push a release every month. With only a few resources, finishing a feature, testing it, stabilising it, and deploying it in a month was extremely challenging. In such a relentless work and delivery cycle, the crew was becoming disgruntled and demotivated. The staff used to work on weekends quite frequently.Then, as project manager, I settled on a major and minor release schedule. A major version was expected to have all of the features operating, whereas a minor release was supposed to have a few performance tweaks, small UI/UX improvements, code clean-up, and so on. Using this method, we were able to maintain the monthly release process for our clients while also keeping the crew happy.

As learned in the PMP Certification course, no one knows better than a project manager what works best for his or her team. Don’t be afraid to create and implement a sound strategy for your team or project.

Another example: when working on a health-care project, my team was battling to keep the bug count down. Customers were continuously requesting for new features, and internal automation process experts were causing a commotion by insisting that all existing product issues be fixed before deploying any new features. As a result, we were at a loss for what to do to please our stakeholders. I reviewed the issue with our internal stakeholders and determined that the team would work on new features in one sprint and resolve high priority fixes in the following sprint. So, every two sprints, we released a new release with a few critical fixes.

This technique also allowed the automated team to test new features before they were deployed, reducing the number of bugs found after the fact. This position also required that I attend bug tracking and triaging meetings in order to negotiate on behalf of my team. Nonetheless, I must state that it took about 4–5 months to bring the bug count down to an acceptable level (and to quiet the process consultants), but the method worked for all of us and met the various needs of the same team and product. It is not always easy to find a solution. However, slight changes may be required to produce long-term advantages.

Need more insights on the same? Take on a credential by Project Management Institute today!