And leveraging it to get to the finish line successfully
TL;DR - Projects are not math equations. There is no 1+1=successful project. However, some steps should be taken as early as possible in order for you to be able to generate an environment that will later help carry your project to the finish line.
Guides and “pro tips” on how to manage and communicate projects exist all over the web. This post offers a different take, instead of a recipe for theoretical success => A toolkit for maximizing the project’s potential. In short:
- Marketing is not only for the outside market.
- To win big - you need to win small.
- DIY approach - when possible, do it yourself.
- Top-down management is not the only option, even for large scale projects.
Marketing is not only for the outside market
Buzz generation - make others see the project’s potential as you see it, constantly, and as early as possible.
As a project manager, you are expected to deliver. In order to deliver, you’ll probably need to get multiple stakeholders, often from different disciplines, to work under a tight schedule and eliminate dependencies and blockers. Hence, you really (really) need to avoid getting to the ominous stage of having other managers telling you: “this task will not be prioritized in the coming sprint, but I assure you we will be back at it in the next one.” An important thing to remember is that a delay of “only one sprint” is as slippery as a slope could be. One becomes three quicker than you think.
To maneuver past this situation, make sure you generate an internal buzz, not in a manipulative way (which will make it worse), but to infect others with how you see the imminent waiting-to-happen impact of what you are leading. If you are enthusiastic about it, spread the word! Make sure that in a situation where there are task conflicts for your team, the easy decision is not to postpone your project’s task.
How is it done? Communicate early successes, make sure the value (or potential value) is shown to the impacted teams, join team standups/daily meetings and remind teams of this project and its impact, early on. You may be leading the best project/idea out there, but if others won’t see it, you won’t be able to progress.
To win big - you need to win small
Quick wins - the end goal is important, but it is built on lots of tiny goals that are met along the way. The quicker you’ll communicate these, the more resources will be allocated to your project.
Everybody loves to win, but how can a team build on that to increase involvement and sense of achievement among the team? There are multiple ways, the common one involves announcing the completion of a milestone. While celebrating it is not to be considered a bad habit, milestones may be insufficient to build momentum on if the milestones are set too far apart. The crucial thing here is to understand that achievements aren’t the only milestones. If you have a plan that you feel confident about - that could be a win by itself. Promote it, tell others about it, discuss it and continue from there. If you have an exciting end-game for the whole project - that could also be a win by itself. Communicate it early to make others join in and suggest better, more refined ways to get there. Doing so will result in bigger wins, until you get to your end goal. Think of it as some kind of a snowball effect, build on tiny wins to become small wins and eventually => BIG WINS.
DIY approach - when possible, do it yourself
If you can do something on your own, do it. When needed, create the initial ideas yourself and let others build on that.
You may not be able to write code, but you are able to do lots of other things. Don’t wait for others with the stuff you can do by yourself. Developer teams are waiting for some Product requirements or a UX/UI design? Write a rough draft and give the relevant personnel (Product/UX/UI designers) something to start from. Start moving the chains. Ask them to go over what you’ve written to cut significant “waiting” times, which are a project manager’s worst enemy. Eliminating blockers and dependencies doesn’t have to be based solely on planning, but could also be done by performing the actual tasks - regardless of role definitions. The designated employee will eventually be in charge of what comes out of it, but a little active nudge won’t hurt from time to time, to speed things up. It will be more challenging to brush a task off if it is just pending review (as opposed to a task that needs to be started from scratch).
Top-down management is not the only option, even for large scale projects
Bottom-up management is your friend, not foe - a small “underdog” team can do magic. Yes, even by self-managing the entire project.
In the context of this post, bottom-up management means that a project is run and decisions are made, from start to finish, by the employees themselves. This enables teams to work as an autonomous unit, without what could sometimes be perceived as “management pressure.” Also, this gives a sense of productivity and “someone counts on me” kind of feelings that are beneficial to the employee’s overall workday experience. This method is recommended for projects that are an attempt at a former failed concept, preferably with “new blood” who weren’t involved in the previous attempts.
Furthermore, This kind of management enables honest communication as employees sometimes fear being 100% open with their superiors (for whatever the reasons are). A bottom-up project enables honest communication by leveling the playing field. No hierarchy to take into account, as the project manager leads the project, but is leading it as an equal among peers.
Now let’s see it in action
Here is an example for all of the above from my own HUMAN experience. The company had a plan to revisit how we deal with internal alerts that are generated by our system, but it could not follow up with a good enough upgrade for some time. Things went well overall so we didn’t have to rush it, but we did want to take it to the next level. After a while of failing to come up with the right way to make the project work, management decided to switch the methodology from top-down to bottom-up. This enabled maximum creative freedom to get the job done, as this was also low in priority and a “let’s give it another shot” kind of project. Thanks to a recent internal technological development, we were underway with our small and goal-oriented team.
The results were evident. After a quick initiation session where management stated the end goal, we figured out who are the right stakeholders and employees to work on the project, and slowly but surely applied our ideas to the system. Most of the ideas were made up following the technical vision we had for the end goal. These ideas were set up and designed by myself (the project manager) and then went up for deliberation with the relevant stakeholders. This process may be the opposite of what frequently happens, where a multi-participant brainstorming session is used to kick things off. Did I mention the “do it yourself” approach? This enabled us to move forward swiftly from setting the vision to implementation, while not surrendering to the project initiation world’s tendency of “falling in love” with discussing different ideas. A back-and-forth discussion around a solid idea, even if not fully baked, is more efficient than brainstorming multiple half-baked ones.
A month later, the buzz was already generated by our enthusiastic team (honestly, extremely enthusiastic team), with quick wins that served as a proof of concept to showcase the potential to others, including higher management. This potential was presented wherever we could, in one-on-ones with direct managers, informal “coffee talks” with fellow employees, daily team meetings, etc. Two months later, we had a solution in place, implemented in the system and fully functional.
The project, by being managed bottom-up, also gave team members the opportunity of being “change agents," an opportunity we all willingly took. Early on, we understood that a new way of dealing with alerts meant that other than the technological change we need to implement in our product, we should use these new circumstances to revisit our alerting processes as a whole. Because different alerts go through different workflows, employees, and triaging processes, we understood that this project will eventually affect a wide-range of areas in the company. We’ve managed to adjust the processes to the new state, with people outside the department in charge of the alerts giving their fresh takes on how we should address the issues at hand. Without following all the early steps mentioned in this post, we could not have been successful with implementing the new technology, executing the much needed complementary changes in the processes, and orchestrating all different parts to create one feasible “alerting mechanism.” A well-planned initiation step led to the project being completed earlier than we thought, with minimal blockers we needed to face while working on it.
To sum things up, there are many ways of making a project successfully reach the finish line. At the end of the day, I personally believe it all boils down to active, effective communication, which could be divided into the talking points of this post. Buzz generation about the ideas and the project’s progress by using quick and small wins as catalysts, actively diminishing “waiting” times together with promoting honest communication by managing bottom-up, as early as possible, should increase the chances of successfully getting to that finish line. And that’s a big win.
