Viewing Posts by Ramiro Rodrigues
by Ramiro Rodrigues
Years ago, I was invited to speak on project management trends to a group of entrepreneurs and businesspeople from small and medium-sized companies. When the subject of knowledge management in a project setting came up, I asked if people agreed that it was important for companies to retain the knowledge acquired for future projects. As expected, there was unanimous agreement.
I then asked people if they had already implemented some kind of system for lessons learned within their company. Only 15 percent of participants raised their hands.
This reflects a common corporate weakness.
Civil, architectural, marketing, research and development, and IT projects, among others, deliver products that rely on the intelligence and experience of those working on them. For these segments, the maintenance of this knowledge, or intellectual capital, offers a competitive advantage. After all, it’s this intellectual capital that allows the recurrence of new business transactions.
Imagine the case of a Brazilian construction company that has been awarded a contract for work in the Middle East. Geography, labor legislation and culture are complete unknowns for the company. The project is expected to experience a high number of challenges and errors. Even so, the project will be delivered. Now imagine that, years after the completion of that project, the same construction company is awarded another contract of similar size in a neighboring country in the region. Even though every project is unique, the knowledge acquired in the first project has immense financial value in helping avoid the same mistakes.
What we witness today is that the knowledgable worker is highly valuable. Imagine that, between the construction company's first and second project, its key leaders leave the company. If the organization has not implemented some kind of mechanism to retain the knowledge acquired during the first project, all the errors (and financial losses) that marked it are highly likely to be repeated in the second project.
And this, in some cases, can be fatal for the survival of the company.
This brings us to a corporate paradox. Most executives are likely to agree that it’s important to develop some kind of knowledge transfer structure. But at the same time, there is clear lethargy in freeing up resources to implement knowledge management systems for projects.
Not that it's simple — initiating any knowledge management process is inherently difficult. There is veiled resistance among workers to explain the knowledge acquired during projects. Either they don’t agree with its importance, find the process annoying or even fear it will make them less essential.
Leaders have to overcome this resistance. Neglecting the issue can put them at risk of being exposed to market volatility.
What challenges have you encountered with knowledge management? How do you make it work within your organization?
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?