Voices on Project Management

When my son was a little boy, he was a great enthusiast of world-class soccer players and enjoyed questioning me: "Is a great soccer player born with talent, or did they practice harder than the others?"

Being the native consultant that I am, I replied to him with another question: "What do you think?" From then on, I was amazed by his train of thought being developed through this old yet complex question.

Through my many years of experience in consulting (and my licentiate degree), I got close to many people who were interested in growing their careers as project management professionals. I acknowledge a sense of pride in having collaborated in different ways with many of these stories. But, as an outside observer, every now and then I find myself asking the same well-grounded question brought up during that talk with my son: "Can a project manager achieve excellence through training and experience, or are there innate characteristics to this professional?"

Perhaps I should begin this reflection by attempting to identify what makes a project manager a successful professional. As it has already been written about before by many others, and aware that the list takes many characteristics into account, I will stick to those traits that I most like to see in a professional:

1. As I like to put it, "projectized thinking," which is basically a mental model where one considers the actual risks and ramifications of these paths. This is someone always seeking to look at what is expected to happen next—they envision a sequential view of activities that consider the troubles inherent to the path and serve as balance points.
2. I also like to emphasize the mental organization capacity of the professional. This ability keeps topics from being forgotten, or having their importance miscalculated.
3. Interpersonal skills are also vital—such as common sense, negotiation capacity and politeness—in addition to other techniques such as communication and technical expertise in project proposals.
4. All of that—as if it were not enough—must be supported by a strong skill to "read" other human beings, which enables us to minimally understand what is going on with stakeholders and what their real interests are.

We probably think that we have some (or all) of these skills. By admitting shortages, it is also natural to imagine that these skills may be developed through some specific training. I agree with that. However, I believe that we may recognize how rare (and challenging) it is to identify all of these characteristics at a high-level within the same professional.

The truth is that there are no effective tools to identify how great we really are in these skills. That's probably why it’s so difficult picking the ideal professional for the job. This is neither good nor bad. Bottom line: We were not born with a binary code that always allows us to go beyond expectations and break the simplistic view that we were destined to become something that we will be until the end of time.

by Ramiro Rodrigues

        The baseline is a fundamental concept that still seems confusing for many project professionals. In essence, the baseline comprises initial reference data captured prior to the start of a project. This information allows the team to compare the status before and after a project to determine its impact.

        Imagine you’re at a software development company and your senior leader has put you on a project to develop a system with 10 different but integrated features. You begin by trying to detail the scope, deadline, costs, risks and all other details you believe to be relevant. Once you’ve collected that information, you’ve reached the end of the planning stage

        That’s the moment when the baseline is saved. With this snapshot of information, you know exactly where the project should be at any given moment in its execution. Right after that—when the project execution begins—you start to draw an actual line, which collects and displays data of what’s happening in real time.

        In our example, imagine you were asked to change the planned programming language to something unfamiliar to the team, therefore changing many of the product’s features. In this scenario, our scope’s “actual line,” resources and risks will be quite different from the “baseline” that had not foreseen this change.

        So, what should the project manager do? It wouldn’t be very smart to resist all changes that come up during execution—these types of shifts can be quite normal in projects. In these cases, the best thing to do is to start the planning process over and move forward. Still, the baseline will continue to serve a purpose in helping leaders identify gaps and finding the amount of effort necessary to reach project completion.

         By project conclusion, another great benefit of this resource emerges: You can compare, with consistent data, the planned results versus actual results. Moreover, a comparative review of the baseline could expose weaknesses in leadership or organization. Indeed, baselines help teams capture valuable information for lessons learned and improvements that can be applied on future projects.

         How do you use baselines on your projects?

By Ramiro Rodrigues

Conflict is inherent to human nature—and that’s a good thing! Conflicts are the fuel that boosts our capacity to think, question and communicate. That said, it is worthwhile to analyze the way conflicts may influence the corporate environment and, more specifically, our projects.

Every project exists to change something, whether it’s creating, improving or replacing. No organization invests its resources into keeping everything as it currently is. But human nature tends to resist change, whether out of fear or out of a desire to preserve comfort.

If every project introduces change, and every change generates resistance, then we can conclude that every project is an instigator of resistance.

How to Manage Conflict

Conflicts typically don’t emerge in the beginning and planning phases of a project. During these phases, the environment in which the project is immersed remains constant. Normally, it is during the execution phase that the team starts to bring to the table the requirements and characteristics expected by the sponsor. During this time, the project leader must stay on the lookout for all potential conflicts that may arise.

Of course, one can’t expect the serenity of a Buddhist monk from this profession. Some of the key emotional intelligence principles, such as resilience and assertiveness in decision-making, are hard to find in a world that is growing increasingly competitive and fast-paced. But this shouldn’t be used as an excuse for negligence when faced with conflicts. The project leader must be skilled in understanding the implications and intensity of conflicts, in order to find the most applicable strategy for bringing about resolution.

Conflict resolution strategies incorporate negotiation techniques that have been thoroughly studied by sales professionals who seek to overcome resistance in favor of their goals.

Stephen P. Robbins, in his book Organizational Behavior, defined the five stages of the conflict process. During the third stage, “Intentions,” Robbins provides five strategies that deserve attention from everyone who needs to handle the clashes that may come up in their projects:

1. Competing: to convince another party of a specific position, regardless of the potential impact it may have on those involved.
2. Collaborating: to seek a result that is beneficial to every party involved.
3. Compromising: to have the parties involved partially let go of their original positions in favor of a common result.
4. Avoiding (non-confrontation): to avoid involvement with the conflict, eventually coming to the point of even denying its existence.
5. Accommodating: to bring peace to the conflict by letting go of a position.

Each unique situation deserves a specific strategy aimed at making the most of the opportunity and enabling your project to progress successfully with low stress levels for everyone involved.

It is indeed possible to extract great results from conflicts. If two heads are better than one, it is understandable that different thoughts may complement one another. Conflicts are opportunities to align messages and to clarify every aspect for the smooth progression of the project, avoiding the development of clashes or confrontations.

I wish you happy conflicts and great projects!

How have conflicts led to better outcomes for your projects?

By Ramiro Rodrigues

In the 2009 film Knowing, a boy finds a time capsule filled with documents from decades ago. His father, an astrophysics professor, then discovers that the messages list some recent and impending major disasters, and even predict a global calamity in the near future.

Apocalyptic visions of an imminent end to the world have always brought joy to the film industry—but they bump into the same logical limitations that are still impossible to overcome. As far as we know, we do not have an effective technology capable of predicting the future. Whether it is related to weather forecasting, economics or sociology, we are not able to tell, at present, precisely what will happen at a specific moment in the future.

What we have always had is a great will to take a chance and get it right. Since the beginning of time, man has ventured to predict the future and, during these attempts, we’ve come up with an ocean of predictions that have been proven wrong. But we don't give up.

A New Model of Scheduling

In today’s organizations, modern project management has to meet the need for schedule development that seeks, in a deterministic fashion, to set the estimated dates of future events related to people, project deliveries and work that will be executed. This usually is a great Achilles' heel in the field of project management. The organizational frustration that results from estimated scheduled activities that turn out to be incorrect is very common.

Why don’t they happen as expected? There are different reasons, usually related to people and intrinsic characteristics of the expected activities. But in essence, they happen because it still is impossible to predict the future. Of course, there are some strategies that can help mitigate the risks of the deterministic forecast, but in the end, they are only predictions.

However, we must understand that organizations need to estimate when the returns on their investments will be accessible for use. Some executives will say that there is no progress without clear and foreseen goals.

That’s right. But how do we get out of this complex scenario in which future dates are determined but do not happen as planned?

One trend that has been applied by industries such as consulting, engineering and research & development is the probabilistic forecast of schedules. In this case, with the assistance of simple statistical concepts, the forecasts of the activities and of the project are viewed as a whole, with probability ranges to conclude them.

It is not solely a mathematical solution; the change is conceptual. The idea is no longer to set, within the organization, the delivery estimates at certain dates grounded on the expectation that they will come true. Rather, the goal is to present length ranges that provide the company with a perspective that there is, for instance, a 68 percent, 95 percent or 99.7 percent chance that the project delivery will take place during the expected dates.

This change in principle allows for the understanding that one can never be 100 percent sure of what will happen in the future but, at the same time, enables the management of the risks involved with reasonable control.

This planning model can bring, in the near future, more maturity and quality to the management of schedules and deliveries.

Do you use this model in your organization? Share your thoughts below. 

By Ramiro Rodrigues

A good definition of the word “maturity” is the state of people or things that have reached full development.

For entities such as business organizations, maturity needs to be associated with a specific expertise. This can apply to operational, technical and also project management maturity.

Project management maturity means that an organization is conditioned to evolve qualitatively in order to increase the chances for project success.

To this end, there are both paid and free maturity evaluation models on the market. The application of one of these models allows you to achieve the first important objective: identifying what stage your organization is at.

This step is difficult, given the complexity in trying to compare whether an organization is doing its projects well in relation to others, without being contaminated by individual and subjective perceptions. Often, most models will question various aspects of how projects are executed and produce a score for ranking. With this result, the models will classify the organization's current maturity level.

Once this level has been identified, the next step is to try to plot an action plan to move to the next level. Here is another benefit of a good maturity model: Many offer references to the most common characteristics expected in each level. With this, it is easier to draw up a plan of action focused on the characteristics expected at the next level. This progress should be incremental—one level at a time.

The action plan should be thought of and executed as if it were a project, following the good practices and methodology of the organization itself. It should be scaled to be completed in time to allow its gains to be observable and perceived by the organization. This will then cause the expected positive impacts in the next cycle of a new maturity survey.

In summary, the steps to be followed are:

1.          Apply a maturity search.

2.          Evaluate and disseminate the results of the first survey.

3.          Develop an action plan.

4.          Rotate the project to the evolution of the level.

5.          Go back to step one and continuously improve.

By following this sequence, you can foster a constructive cycle in your organization as you continue to evolve your ability to execute projects.

I’d love to hear from you: Have you used maturity models in your organization?