Viewing Posts by Ramiro Rodrigues
By Ramiro Rodrigues
I have heard arguments both for and against the effectiveness of corporations using standardized project management methodologies.
In general, a project management methodology should clarify which methods — steps, activities, gadgets and tools — can be used to reach a goal. And since a project is made up of a set of processes, each with their suggested methods or best practices, they are usually given the name of methodology.
The Arguments For
The fervent proponents of project management methodologies contend that there is a need for the implementing organization to establish an identity, which its clients will see. They believe that the methodology enhances the standardization of the particular strengths of the services offered.
According to them, a project originating from a corporation with a specific work methodology tends to have more predictable services and products, which decreases the interference of human factors associated with the individuals who lead the project. It also allows for greater clarity and understanding for the stakeholders with regard to what is to be expected at each moment.
Finally, they maintain, that a methodology enables a virtuous cycle of continuous improvement and development with regard to project management in an organization.
The Arguments Against
Opponents assert that methodologies often require disproportionate documentation efforts that do not add value. For them, methodologies are bureaucratic "machines" that increase their costs and stress levels, thus taking the focus away from the expected results.
There is no single solution to this issue. It is common knowledge that each organization must develop its own project management methodology in order to find the best set of methods.
Therefore, it is suggested that organizations wishing to improve should always consider whether the proposed methodology:
This latter issue, together with the need for resource optimization and a drop in the learning curve, has led corporations to search for alternatives — such as agile methods and using Canvas in project management.
However, this objectivity "line" should not be stretched too far. There’s a risk that while searching for leaner processes some aspects related to the optimal handling of a project may become too superficial. That could ultimately compromise the quality of project deliveries and the image of the implementing organization.
Therefore, there is no one perfect solution. Each market segment, project size and organizational culture should be carefully considered in order to find the best way to implement a project management methodology.
by Ramiro Rodrigues
Consider the following situation: You have worked a long time in your company and developed a certain level of expertise in their operations. You are familiar with the processes, tools and people.
One day, a consultant, hired by the board, arrives at your desk and lets you know that they are there to lead a review of the company's processes. As such, they will need some information about the way you work. It doesn't take long for you to realize that the consultant's job is to change your familiar operational format.
This scenario illustrates my main point: Every project is a change.
Organizations have an established understanding that standing still could be fatal to the survival of the business. They need to innovate and be faster than the competition. This is what motivates them to invest resources in pursuing these goals. Thus, the basis of every project is the facilitation of a change that will shift them from point "A" to point "B", which is, theoretically, more advantageous.
Everything would be perfect if our human reasoning didn't, for the most part, take us in the opposite direction. Instinctively, people do not like to mess with what they already know. (Unless, of course, they’re in situations that are uncomfortable. Even in these cases, they have their reservations.)
Our nature instinctively seeks out security and stability, which often is possible only through various mistakes and persistence. "Projects" are at odds with these principles because they are associated with the uncertainties and fears that the changes will bring.
Knowing this, if the individual in charge of a project wishes to succeed in their mission, they must develop interpersonal skills — the capacity to communicate, negotiate and intervene. These skills are part of the arsenal of resources that a good professional needs in order to persuade those involved to commit to change.
It is not easy. For this reason, professionals who are adept at these projects have gained increasing appreciation in the corporate market. This is because they take on the responsibility for ensuring that the investments made are not lost and the failure statistics are not intensified.
But human instinct will resist. In this scenario, one of the possible strategies is to adopt Charles Darwin's evolutionist principle, which is wholly befitting to today’s frenzied corporate world. It is not the strongest species that survive, nor the most intelligent, but the one who can best adapt to change.
by Ramiro Rodrigues
Project managers: Are you sometimes looking to make plans faster but without being superficial and therefore riskier to the project?
Developed in the 1980s, design thinking is a structured mental model that seeks the identification of innovative solutions to complex problems. Although the concept has existed for decades, it’s only made its presence known in the corporate environment over the last 10 years.
Swiss business theorist and author Alexander Osterwalder similarly sought to accelerate collaborative reasoning when he introduced the Business Model Canvas. Canvas helps organizations map, discuss, rework and innovate their business model in one image.
But a series of proposals for the use of the Business Model Canvas for various purposes outside of business models has also appeared — including innovation, corporate education, product development, marketing and more.
For project professionals looking at alternatives to developing quicker and more collaborative planning, Canvas may sound like a great option. Of all the proposals that come up for the use of Canvas in a project environment, integrating stakeholders may be the best. Canvas brings stakeholders into the process and will help to minimize resistance and increase collaboration, resulting in a better proposal for planning problems and making the project more aligned to the interests of organizations.
But while the arguments put forward for Canvas all seem positive, there is still a dilemma: Can Canvas fully replace the overall project plan and the planning process? Is it possible to do without a schedule of activities, a detailed cash flow, a matrix of analyzed risks — just to limit ourselves to a few examples?
That is probably too extreme.
The general sense is that the integration of Canvas with specific planning — such as the cost plan and the risk plan — is the most productive and generates the best results.
It may be worth asking your project management office for their thoughts.
Have you ever used a Canvas for your project planning efforts? If so, what tips can you share?
By Ramiro Rodrigues
In my last post, I shared tips for closing external projects. Now it’s time to tackle internal efforts.
As part of this discussion, it’s worth remembering that PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not differentiate between the origin of the customer (internal or external) for the scope verification process.
So even if a project is internal, project managers should obtain acceptance and have at least one approval by the customer in order for the project to be formally closed.
A crucial question to consider: What does your organization's project methodology say? Are you required to get a form signed to show formal acceptance at the end of the project? If so, the good news is you’re closing process is outlined for you.
It gets complicated when you’re not required to sign a formal document or there is no defined methodology for closing an internal project. It creates a great organizational trap for project leaders as projects that are not formally completed tend to repeat the phoenix fable: a project is resurrected over and over again with new work requirements because there is no record of a signed agreement signalling the completion of the work.
Imagine having to re-run a project months—or even years—later when there are no more resources, schedule or budget available to execute the remnants that emerged? On top of this, you’re probably already involved in other assignments, and you may not even remember the full context of that project.
The most effective strategy for not falling into this trap is to produce an informal document of acceptance—a simple text that describes the macro deliveries of the project scope and send your customer a hard copy or email copy. But be careful to include a text that makes it clear that the parties (you and the customer) agree that the deliveries quoted have been made to the desired quality.
And make sure you receive acknowledgement—even a simple “okay” response will be sufficient to file the document and to protect it from unwanted resurrection.
How do you ensure internal projects don’t come back to haunt you in your organization?
By Ramiro Rodrigues
When outsourcing a job to consultants and service providers, I’ve often found that achieving "agreement" with a client that a project is finalized is one of the most delicate times.
This is usually due to the fact that by closing the project the client knows that:
Scope verification—the process of formalizing the approval of a project scope—recommends progressive approvals are made as partial deliveries of the scope take place. This process, if well planned and applied, helps to minimize the weight of the final approval term.
The strategy I developed over many years of consulting work is something I call “ground preparation.” This strategy has four simple stages that need to be well distributed in the time near the project closure to increase your chances of a non-traumatic closure.
Let's review them:
1st Stage: As you move close to the end of the project, start the conversation, preferably face-to-face, with the stakeholder responsible for accepting the project.
2nd Stage: Send that same stakeholder a draft version of the project acceptance document that is as close as possible to the final version.
3rd Stage: After giving the stakeholder time to digest the draft, follow up to discuss any questions or concerns. Also, this is a good time to let them know when they can expect the final acceptance document.
4th Stage: Send the final version of the acceptance document and suggest that you collect it with, if applicable, some sort of closing event.
Of course, we are talking about a project that has successfully achieved its goals. But even projects that have had to be aborted or projects with a low degree of success at the end must be formally shut down. A lot of this strategy can be replicated whenever the end is imminent.
What are your strategies for closing down a project?
In my next post, I will review the characteristics of the acceptance term for internal customers.