Always be proactive
There’s a natural tendency in us to be reactive. It can help us preserve our energy dealing unimportant matters, or it may give us better results when we are dealing with something in which we’re completely incompetent. Those situations are different from our projects, and here we can get better results by being proactive.
Example: Planning
If you want to drive to a new location and you’re late, you can start driving immediately to “save time”, and deal with possible problems when they arise. The proactive approach is to take some time at the start and set your navigation system to give you the fastest route based on the traffic and possible accidents and blockages and then drive; that’s spending time before executing, to avoid problems later on and thus save time in the end.
In contrast to what some people think of Agile projects, planning is always necessary, and it’s only about the type and level of details in plans. Planning before executing is a proactive approach.
Remember the quote: give me six hours to chop down a tree and I will spend the first four sharpening the ax.
If it’s a predictive project, you may spend 4 hours sharpening your ax, because you’re sure that you’re going to chop down a tree. In an Agile project, you’re not sure if you’re going to chop down a tree, gather broken branches, harvest turf, mine coal, or something else. Nevertheless, you still need to have a general preparation for all of those (know where the nearest hardware store is), and have a specific preparation (sharpening) when you’re going to focus on a certain solution; that’s planning.
Example: Planning the planning
Planning the way we’re going to execute the project is a proactive approach. This proactivity can even be extended by planning the way we’re going to plan the execution; that’s the management plan concept of the PMBOK® Guide, management strategies of PRINCE2®, and approaches in DSDM®.
Example: Continuous planning
Reality rarely matches what we have planned, and that’s OK – but, we have to continuously adapt our plans to make sure they stay realistic and practical. We should do it as soon as adaptation is needed, and not when we run into problems. That’s a proactive approach.
Example: Risk management
The whole concept of risk management is based on proactivity: when facing uncertain events, instead of waiting to see what happens and then reacting to them, we think about possibilities and impacts, consider responses, and probably do something about it before it happens.
Note that what we do in projects is serious; it’s sometimes about people’s lives.
Example: Define roles and responsibilities
You can leave the project team members to work without clear roles and responsibilities, and sooner or later a form of roles and responsibilities will emerge, but it’s too expensive and may not work well after all. The proactive approach is to define them early and adapt them as needed. This makes working easier for everyone, and they can focus on producing something, instead of deciding who does what.
The number and variety of roles depend on the type and size of the project; it can be a simple definition such as the one in Scrum, something moderate such as that in P3.express, or something comprehensive like the ones in DSDM® and PRINCE2®. However, don’t forget that the role descriptions in these methods are only about management activities, and that you always need to add role descriptions for technical aspects as well.
Example: Available choices
Should you close the project prematurely or continue with it?
There are rarely only two choices, even if the question implies that. You need to have a proactive approach and consider all your choices before making a decision. Maybe you can rescope the project; maybe you can pause it until something else becomes clear; or maybe you can change the project approach (e.g., outsourcing), etc.
Example: Critical thinking
We all have many biases that help us survive on one hand, and fool us into making bad decisions on the other. When it comes to making important decisions about the project, it’s best to pause for a while and consider all biases that can impact our decision before they cause problems.
As a reference, you can use the list of cognitive biases given in Wikipedia: https://en.wikipedia.org/wiki/List_of_cognitive_biases
There are even decision-making frameworks that you can use to make better decisions. At first, it may be distracting and even annoying to use them, but soon you get used to them and gain advantage from them without much conscious effort.
Example: Transparency
We don’t like being late in the project or having any other kind of problem, but it doesn’t mean that we should hide it. You should be transparent and let the stakeholders know, because some of them may be able to help you, and furthermore, they will know about the problems and their consequences sooner or later, and some of them may require early actions from their side (e.g., to accept the negative consequence).
Example: Communicate effectively
There may be many cases in which you send reports to stakeholders and they don’t give you any feedback. You may believe that everything is fine just because there is no negative feedback, although it may not be so. You have to be proactive and check to see whether they’ve really used the report and whether it has served the purpose, and use the input to adjust your method of communication; otherwise, this hidden issue may cause serious problems later, when it’s too difficult to fix.
Example: Take responsibility
It’s easy to blame others for poor results. For example, you may want your organization to give you full authority to change everything in the project and do it perfectly, but they don’t, and as a result, the project fails. This is not a proactive approach.
The proactive approach is to take responsibility and do everything you can within the constraints. You cannot expect the organization to fully trust you and give you everything in the hope of getting good results, especially when they have seen so many failed projects. What you have to do is to make one small improvement within the constraints that are set, use that to gain a little trust, a few more resources and a little more toleration for constraints, and then use that for a slightly bigger improvement, and carry on like that until you reach the optimum target.