Bring it on
BY MICHELLE BOWLES JACKSON
Change isn't always welcome—a fact project professionals know all too well. Even though automated project management tools are intended to make teams more efficient and effective, introducing them within an organization can cause a big shakeup.
Executives might see the tool as yet another big-ticket item, while team members might see it as an additional task to eat up their valuable time. These factors are amplified when the tool is implemented in an organization with low project management capabilities.
Whether the tool being deployed is a ticket-tracking system, enterprise resource management software program, wiki or mobile app, software decision-makers need to keep these nine considerations in mind.
Don't use the tool to increase your organization's project management abilities. In less projectized organizations, there's a tendency to purchase a tool and assume it will immediately lead to project management success.
“It will not,” asserts Elizabeth Larson, PMP, CEO of Watermark Learning, a project management and business process training and coaching firm in Minneapolis, Minnesota, USA. “Often, these organizations struggle to get projects under control after they go down the path of a tool.”
Organizations that gain a solid understanding of project management principles before implementing any automated tool tend to have better longer-term project success rates, she says.
Realize that process comes first, tools second. Oftentimes, organizations may mistakenly expect automated project management tools to make up for a lack of processes, says Joseph A. Sopko, PMP, OPM3® Professional, Princeton, New Jersey, USA-based senior project management consultant at Siemens Corporate Research, the innovation division of the engineering conglomerate. “If you don't have standardized and defined processes, the tool is not likely to be used to its full capabilities and deliver the intended benefits.”
Organizations should first identify the areas where the tool will apply—project control, planning, scheduling or resource management, for instance—and define processes for those areas.
“If you have low maturity, look at the processes recommended by A Guide to the Project Management Body of Knowledge (PMBOK® Guide) or other standards associated with the tool being implemented,” Mr. Sopko advises.
Have a clear, specific goal in mind when selecting a tool. From wikis to mobile apps, and from software to cloud-based solutions, there is no shortage of automated tools that can help organizations improve their project management prowess. But the tool must answer a very specific business need.
“Tools are not a replacement for improving organizational project management maturity,” Mr. Sopko says. “Higher-maturity organizations tend to gain the most potential benefits from project management tools and information systems.”
For instance, after implementing resource management processes within project teams, an organization might want to gain a more efficient way to identify and manage resources. Only then can it determine which tools would be most effective at achieving those goals, he explains.
The objective must also be defined in a way that makes the effectiveness of the tool measurable, Ms. Larson adds. Improved reporting capabilities, for example, can be quantified.
Understand the difference between “capabilities” and “benefits.” A tool can provide all the capabilities under the sun—but stakeholder groups are more likely to buy in when they see the benefits. The person in charge of purchasing and implementing the tool must be able to explain—and then measure—the benefits they are trying to realize with a tool, Mr. Sopko says.
It's a similar situation as when an organization implements a new IT system. “The new system goes live on time, it provides all the capabilities it was supposed to per the specs, and it was delivered on cost,” he says. “But then you ask the organization, ‘Did you ever get the benefits the system was meant to deliver?’ And they say, ‘No.’ The same thing happens with project management tools.”
of purchasing and implementing the tool must be able to explain—and then measure—the benefits they are trying to realize with a tool.
—Joseph A. Sopko, PMP, OPM3® Professional, Siemens Corporate Research, Princeton, New Jersey, USA
Speak the language of the executive suite to gain buy-in.The expectations of executive stakeholders must be translated into specific numbers or results, says Panayotis Agrapidis, CEO of Organization Strategic Systems, a portfolio, program and project management consultancy in Athens, Greece. For example, if a portfolio manager wants to gain executive buy-in for a new tool with advanced reporting capabilities, he or she should present hard numbers:
- The actual time it currently takes to pull a specific report
- The estimated time it would take to pull the same report with the new tool
- The estimated report accuracy achieved as a result of the new tool
You don't want just any metrics; you want the data that matters most to senior management. It's not enough to simply provide schedule or cost variance, Mr. Sopko says. You have to communicate the value of time to the organization. “For instance, if you deliver a project one week earlier or later, what does that mean in terms of increasing or decreasing value to the organization?” he explains.
Get the team comfortable with the tool. Team members can be hesitant to introduce a new process into their workflow—even if the solution is intended to help make their work lives easier. To further complicate things, they might not clearly communicate any concerns.
“Teams that are not used to working with project management concepts might be terrified of a new tool because they think their work will be micromanaged,” Ms. Larson says. “They may react adversely and view it as added bureaucracy and imply that learning a new tool gets in the way of getting the job done.”
Address user concerns and build trust by helping team members understand why the tool is being introduced.
“If you are asking them to track their time through an automated tool, show that you're doing it to benefit the team rather than to judge personal performance. For example, tracking the actual status of the project might help gain additional resources for the project team,” she says.
working with project management concepts might be terrified of a new tool because they think their work will be micromanaged.
—Elizabeth Larson, PMP, Watermark Learning, Minneapolis, Minnesota, USA
Consider interoperability issues. Regardless of the type of automated solution chosen, organizations must assess the potential impact on existing tools, Mr. Agrapidis says. When selecting software, organizations must ensure that it's capable of exchanging data and interacting with previously installed software and databases.
Similarly, any mobile app chosen should provide complete interoperability with installed applications, as well as support both iPhone and Android devices, he says.
Support team members as they get up to speed with the tool. Training team members on the new solution is especially crucial in non-projectized organizations, Ms. Larson says.
“Some team members might not understand the concept of the tool and might fear looking foolish if they don't know how to use it,” she says. “Have someone sit down with the team members to train them on how to use the tool and then provide coaching. You need a supportive environment to gain buy-in.”
Treat the tool implementation as a project. Regardless of the type of tool being introduced, the deployment should be planned in the same way as any other internal project, Mr. Sopko says.
Adopt a step-by-step approach and set specific targets over short periods of time, Mr. Agrapidis suggests.
“Anyone implementing an enterprise project management system, for example, should provide a plan and a schedule for how to get the system up and running. There should also be a program through which the tool delivers benefits and sustained organizational improvement,” Mr. Sopko says. PM
PM NETWORK FEBRUARY 2012 WWW.PMI.ORG
FEBRUARY 2012 PM NETWORK