Viewing Posts by Ramiro Rodrigues
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.
Imagine this scenario: You are the project manager of a new, strategic project of your company. Excited, you prepare the necessary documents and schedule the project's kick-off meeting.
The kick-off meeting seem to be going well, until you start presenting the necessities and you notice resistance coming from functional managers in ceding their resources.
And it’s only then you realize your mistake: You should have invited the project sponsor to the kick-off.
Kick-off meetings, which should take place between the end of the planning stage and the beginning of implementation, are of paramount importance to the success (or failure) of a project. And you must prepare.
For the project manager, the kick off is a great opportunity to ensure that your stakeholders are identified, to demonstrate that there is a common gain in the success of the project, to map out the stakeholder predispositions and to ensure that their respective roles are understood.
Here are four things to keep in mind:
1. The Invite List: You must have the other relevant stakeholders in the room—functional managers, the customer of the project product and all those who can have an influence, either positively or negatively.
2. The Meeting Infrastructure: The size of the room, amenities, coffee break and everything else that make the environment appropriate.
3. The Presentation: The kick-off meeting will be your moment to demonstrate that the project is well planned with mapped risks. But, keep your audience in mind. For example, the sponsor, usually an executive with no time to see the details, will be present at this meeting. Make your presentation concise and objective by showing that you have a clear vision of where you want to go.
4. The Sponsor: The great benefit of the kick-off meeting is to get commitment to the development and success of the project. Without it, the project manager always runs the risk of having their needs not met. This is where the essential participation of the sponsor comes in. He or she typically has a politician's nature.
Even though it is up to the project manager to conduct the meeting, it is essential that, soon after the welcome is given, the project manager gives the floor to the sponsor. They can use their position within the organization to "suggest" to those involved to give their support, resources and conditions to the project manager on behalf of the expected results of the project. With the sponsor message given—even if he or she leaves right after they speak—there is a greater chance that everyone else will understand and support the project and that will make the rest of the meeting easier for you.