By Mario Trentim
There's an old saying: "A fool with a tool is still a fool.” And I’ve heard many project management professionals say that best practices and good methodology are more important than project management tools and software.
Do you agree? By the end of this article, you might change your mind.
A Brief Story of a Failed Methodology
I've been working as a project manager since 2001. In my early days, as an engineer, I was responsible for the technical and managerial aspects of projects. In 2010, as I moved up the ladder in my organization (the Air Force), I was assigned to implement and operate a Project Management Office (PMO). Considering that we didn't want to make large investments up front, my focus was on creating a methodology, developing templates and designing and delivering training. To my surprise, only a few of my recommendations were implemented, even though abiding by the PMO guidelines was mandatory.
I started investigating the reasons. It turned out that it was not that people didn't know the methodology, nor that they did not want to follow it. It was just too much work.
You know the drill: A project manager is assigned to a project, searches the intranet, finds the PMO site, then reads the "project management manual" and any other supporting documents for the methodology. Finally, the project manager copies and pastes files from a shared folder, and starts filling in all the templates (scattered in different files and different formats).
Truth be told, the project managers usually started on the right foot. The problems appeared as the project progressed, because it was a huge effort to keep all files updated and integrated in a coherent fashion.
Although I am talking about experiences from 2010 to 2014, many organizations unfortunately still find themselves in a similar situation today.
Productivity goes down. Project failure rates go up. And as the organization demands more training, it creates more controlling processes, auditing and extra reports—resulting in even more work.
When I first came across Project Portfolio Management (PPM) and Enterprise Project Management (EPM) software in 2003, I didn't think it would be a big deal. By 2010, I was convinced that you cannot increase portfolio and project management maturity without software.
To be able to implement a standard toolset across projects, the PMO usually starts with paper-based or Excel-based approaches. The risk is that they settle for less by not evolving into using enterprise-level business applications.
Is adopting a particular tool or software a requirement to project management success? No. But the use of project management tools increases maturity.
People often say that they will acquire a corporate project management tool once their organization is "mature enough." Going back to the beginning of this article, I am very aware of the fact that a tool is useless if you don't know how to use it. However, once you already have basic knowledge and processes, a tool can speed up the learning process—skyrocketing productivity.
As an analogy, imagine that you already have basic knowledge in math and finance. When should you buy a financial calculator, such as HP-12C? Only after five years of calculation amortization by hand? I doubt this would be the smartest choice. After all, you don’t have to become an expert bike runner before you can buy a bicycle.
In project management, some of the foundational concepts can be taught by using flip-charts, sticky notes and simple Excel spreadsheets. But you cannot teach people how to create a solid and realistic schedule and cost baselines without project management software. It is just not feasible. It is not that it is impossible. Actually, in the 1960s and 1970s, the Polaris and Apollo projects were planned without the help of software tools (nonexistent at the time). But planning for those projects took a long time.
Today, we live in a modern world in which the project life cycle is shorter. We manage multiple projects at the same time, and there is more volatility and uncertainty. Project managers have to evolve as well.
How to Implement PPM and EPM Tools
Project Portfolio Management or Enterprise Project Management is a corporate platform to manage portfolios, programs, projects and resources enterprise-wide. The PMO is ideally positioned to lead project management tool selection because it understands the big picture from different project managers, team members and business units. When assessing specific project management tools, take into consideration:
Depending on the size of the organization, you might prefer to execute a pilot before rolling out the tool to the entire organization. It is important to keep stakeholders engaged and informed by sharing:
A word of caution: Do not underestimate the effort needed to implement a project management tool enterprise-wide.
In the meantime, please leave your comments and questions below.
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 Wanda Curlee
What is the state of portfolio management technology?
That, of course, is a loaded question. Many factors—including the company and the industry—come into play. Nevertheless, most will agree that the tools of portfolio management have progressed.
While portfolio management can still technically be done with spreadsheets, it’s a labor-intensive approach that doesn’t make sense for every organization. So, if you’re ready to upgrade your spreadsheets, how do you know what tool is right for you?
If your organization lacks the expertise, you may need to hire a consultant to help. A consultant can assess the situation and determine the most effective approach to follow. It might be as simple as creating spreadsheets that need to be completed and analyzed differently, or as complex as implementing a new customized tool.
Whether you hire a consultant or not, picking the right portfolio management tool for your organization is a project. And there are many moving parts.
1. Create a wants and needs—or requirements—list. As many of you are already well aware, this is a wish list and there is probably no tool that will meet the full list. The requirements need to be ranked and maybe even weighted to provide a true assessment among tools. One tool may provide only one highly sought requirement but many less-desired requirements. On the other hand, another tool may provide multiple highly sought requirements but no less-desired requirements.
The weighted average can help those make a case for one tool over another. Those making the recommendation should be different from the final decision maker.
2. Customize the tool. The customization should not be done with rose-colored glasses. There should be a pilot program to see if the requirements are producing the results expected or if tweaking is required.
3. Begin implementation. Since this is a portfolio, I would recommend the big-bang approach. That means all projects and programs within the portfolio must be loaded. They need to be analyzed to ensure that the correct information is inputted. The project and program managers need to be trained to understand what is needed on the new tool. Remember, most portfolio tools also work for some (or extensive) project and program management.
Team members working in the portfolio need to be trained as well. Those producing reports and what-ifs must understand how the tool does these things correctly. Without understanding the tool, results may be less than adequate.
4. Compare the before and after state. Once the tool is implemented, the portfolio manager should run a couple tests to see if the previous state and the new tool produce similar, if not exact, results. If not, then there is an issue that needs to be resolved. It may be an easy fix, but more than likely there will need to be some analysis done.
Remember: A tool is not a silver bullet. However, if you have a large portfolio, a tool might be necessary. But don’t expect miracles. You will still have to do the value-add!
By Ramiro Rodrigues
The term path is used for a sequence of activities that are serially related to each other.
Imagine, for example, that your colleagues have decided to organize a barbecue. After dividing up the work, you are responsible for hiring the catering services. For this task, you are likely to have to look for recommendations, check availability and prices, analyze the options and then choose the best one. These four activities are a path. In other words, they are a sequence of activities that must be carried out sequentially until a final goal is achieved.
A project manager’s job is to estimate the duration of each planned activity. And if we return to our example, we could consider the possible durations:
This sequence of activities will last 40 hours, or five workdays. And since the whole barbecue has been divided among various colleagues, other sequences (or paths) of activities—such as choosing the venue, buying drinks, organizing football, etc.—will also have their respective deadlines.
The critical path will be the series of activities that has the longest duration among all those that the event involves.
Let's imagine that the longest path is precisely this hiring of the catering services. Since the process is estimated to take five days, the barbecue cannot be held at an earlier time. And if it were held in exactly five days, all the activities involved in the path have no margin for delay. This means that if, for example, my analysis of options is not completed on the date or within the duration planned, then the barbecue provider will not be selected in time, which will invariably lead to the postponement of the barbecue—and leave a bad taste in my co-workers' mouths.
Under the critical path method, there is no margin for delay or slack. If there is a delay in any activity on that (critical) path, there will be a delay in the project. At the same time, other "non-critical" paths can withstand limited delays, hence the justification of the term.
It is the duration of this path that is setting "critical" information for all projects—when all the work will have been completed.
Do you use the critical path method in your work? If so, what are your biggest challenges?
By Conrado Morlan
“If all you have is a hammer, everything looks like a nail” - Abraham Maslow
Over the last two decades, the project management profession has rapidly evolved. The number of professionals has grown worldwide, organizations have adopted, adapted or created frameworks and methodologies to support their projects, and technology has flooded the market with a plethora of mobile, desktop, server and cloud tools.
These tools are big players in establishing the ideal project management environment for organizations that want to track project metrics, performance, pipeline optimization, resource management, time, cost and budget—and the list can go on and on. These versatile apps also support an endless range of frameworks and approaches, from waterfall to agile to Kanban.
Organizations may go thru a selection process to choose the right tool for their environment. Many support their decision-making process with external sources from consulting companies that had reviewed several tools and classified them based on different criteria.
Once a tool is selected, the next step is to put together the various pieces of the puzzle—the project, practitioners and tool. They don’t always naturally match up—and that’s to be expected. That means training.
However, I’ve recently noticed a disturbing trend. I’ve seen several job postings in which the most important trait is the years of experience using a particular project management tool. Some of the job seekers told me that they did not get the job because of their lack of experience in a particular tool.
It makes me wonder: Are organizations “toolizing” project management? Are they boxing themselves into a tool environment? Why is a tool more important than a discipline?
Experienced project professionals exposed to different frameworks or project management methodologies may apply their knowledge to the tool and manage the portfolio, program or project. A tool expert does not make a project management professional.
Remember, at the end of the day, a fool with a tool is still a fool.
Do you think organizations are becoming “tool-centric”? If so, what’s driving this trend?