Contributed by Sonali Malu
Do you run your projects using process, or strategy? Sometimes we even hear that these terms are used interchangeably. But they are not the same.
- A process essentially has certain steps involved to complete it; A strategy may not always have the same set of steps.
- A process is always a part of the strategy; A strategy is designed based on organizational objectives.
- A process may or may not be defined by top management authorities, but a strategy is always defined by top management authorities.
- A process has definite input, output, and tools, and techniques. A strategy may have a number of plans, processes, projects, tools, and techniques involved.
As a project manager, I do follow the processes as tailored for the project and see that processes are followed by the team as well. However, simply by following up the processes desired results are not achieved. So, in order to get the desired outcome from the team, strategies need to be established by a project manager for a project.
For Example – I was working with an organization in scrum framework where it was necessary to push a release every month. But it was very difficult to finish a feature, test it, stabilize it and deploy it within a month with a handful of resources. The team was getting frustrated and demotivated in such a constant work and delivery cycle. Many times the team used to work over weekends. Then as a project manager, I decided to have 1 major and 1 minor release. The major release was supposed to have full working features while a minor release was a few performance improvements, simple UI/UX improvements, code cleanup, etc. Using this strategy, the process of a release every month for our customers was kept intact; keeping the team content as well.
No one other than a project manager understands what works well for his/her team. Do not hesitate to develop a correct strategy for your team/project and implement it.
Another example – While I was working on a health care project, my team was struggling hard to keep the bug count low. The product was already launched, customers were constantly asking for new features, and the internal automation process consultants were making a hubbub that all existing bugs of the product should be fixed before launching any new features. So, we were in a bind as to how to satisfy our stakeholders. I discussed the issue with our internal stakeholders and decided that team will work on new features in one sprint and in the subsequent sprint team will work on the resolution of top priority fixes. So, after every 2 sprints, we pushed a release out with a few important fixes and also with a new feature. This strategy also allowed the automation team to validate the new feature before they were released – this, in turn, reduced the number of post-production bugs as well. This situation also demanded I participate in bug tracking and triaging meetings so that I can negotiate for my team. Nonetheless, I must say that it took around 4-5 months of time to bring the bug count to acceptable limits (and to suppress the hubbub of the process consultants) but the strategy worked for all of us and satisfied the different purposes from the same team and product. Sometimes the solution is not straightforward. But, in order to achieve long-term benefits, small adjustments can be required. These small workarounds are nothing but strategies that play a vital role in the journey towards progress.
About the author
Sonali Malu has more than 14 years of experience in software, web development, and project management in the Information Technology industry. Experienced in diverse domains like web portals, web applications, health care, and automotive. Sonali focuses on continuous learning, is always happy to share those learnings and observations through written articles, teaching, or speaking engagements.
For more about Sonali – https://www.linkedin.com/in/sonali-malu/