"The more professional your project manager is, the less their subject matter expertise," Vitasek says. So it's important to surround the professional project manager with strong subject matter experts, who serve as members of the core project team.
"The core team has ownership and accountability for the successful completion of the project," Vitasek says. "The team is also responsible for executing project activities rapidly and according to plan, for reporting progress to the project executive, and communicating and resolving issues when they arise."
Six to eight is a good number of people for the core project team. "More than that, and the team gets bogged down with too much discussion and debate during project meetings," Vitasek says. If you need a larger team, she suggests using layers of sub-teams for greatest effectiveness.
When putting the team together, make sure you tap individuals with the right mix of skills, experience, and style, Read advises. The project team should include "a blend of people with different staff and field responsibilities and a blend of functional capabilities" to ensure that all viewpoints are included in the project planning and implementation.
"You also need diversity and expertise," he says. "If you have a group where everyone has the same style and/or personality, the effort will be single-dimensional," which can lead to a less than optimal result.
The right plan. "For a complex project to be a success, there needs to be a plan that spells out the schedule, tasks, responsibilities, and roles," notes Ben Gunter.
The plan also needs a clear statement of objectives that describes the purpose of the project to ensure that everyone involved understands the overarching goals and objectives.
The preliminary plan, used to develop the business case, should be expanded to include detailed specifications and cost estimates. Included in the project should be a detailed statement of work.
"This is a very detailed document that spells out responsibilities and accountabilities, including deliverables, milestones, and expected results," Vitasek explains. The statement of work -- which can be as long as 100 pages or more -- helps ensure that all parties involved have a very clear understanding of what they're expected to do, and by when.
Yet, Vitasek says, a number of companies don't take the time to develop a statement of work.
"Preparing one is a large amount of work that requires thinking through the project up front. Many companies want to get going with the project rather than investing the time in up-front planning," she says. But the effort pays off in the long run.
Working Backward
To develop the plan, "I look at the end result, then work backward to identify what needs to be done to reach the end-point," Sisko says. "It's a backward explosion, a branching that goes in reverse."
This approach can be more manageable than starting at the beginning and working toward the end, Sisko says. "If you start at the beginning, there are thousands of things to consider," he says. "Start at the end, and there's only one result. This helps prevent you from becoming overwhelmed."
A complex project, requiring months or a year for development and implementation, may have as many as 500 to 1,000 tasks that need to be managed, Gunter says. If you don't have anyone on your team who can produce such a detailed plan, he says, it's time to bring in project management help, whether it's from elsewhere in the company or an external resource.
When the plan is implemented, Gunter says, senior management needs to review it regularly, comparing progress to the plan so that timely action can be taken if the project veers off-track.
The right measures. Project metrics can help ensure that the project stays on track from both a budget and schedule point of view.
"You need a few clear metrics of budget and timeline to monitor," says Read. "If you have too many ways to assess progress, then it's tough for the project manager to see the overall message. It's better to have a few metrics that indicate how well you're doing."
For example, Read suggests tracking resources employed -- such as actual dollars or people-hours relative to goals -- and percentage of completion of key deliverables and milestones met.
Measuring "bug days" can be effective for systems implementations, Gunter says. Bug days are the number of days that elapse between when a bug is reported to the systems vendor to when the bug is resolved and the change delivered to the job site.
"We found tracking 'bug days' as we went through systems testing to be very revealing -- it provided a single number that could be plotted, charted, and presented to senior management."
Gunter suggests tracking the total number of days bugs have been outstanding. For example, say you have two bugs that have been outstanding for 20 days each, one for 12 days, and one for three. The total number of bug days in this case is 55.
"You expect no bug days when the project begins, but as it ramps up, you start to expect them," Gunter notes. As the vendor delivers fixes, the number of bug days should drop, then may ramp back up as more testing is conducted.
"Eventually, the number of bug days should taper off to zero. If they don't, be prepared to find a way to extend your testing period," he advises.
It's also important to measure your project team's performance, Vitasek says. "If you put a metric on the project team, they know they're being held accountable."
The right approach. "A number of project management techniques can work well," Vitasek says. "The point is to have one and use it," and ensure that project team members are trained in how to do so.
Whichever implementation approach you use, it should be "well-structured and monitored, and based on a series of small successes," according to Bill Read. Managing to interim milestones is particularly important with highly complex projects, he says.
"The more complex the change you're trying to drive, the better your chances of getting there if you can demonstrate improvement along the way via small successes, rather than waiting for a longer period of time to achieve something radical," he says.
The right project management approach balances what Kate Vitasek calls "the four S's -- scope, staff, schedules and $ [dollars]".
"Think of it as a diamond -- you're trying to keep the diamond in balance. If your scope is huge, but you don't have sufficient people, the project won't be successful. If it's an enormous project on a short schedule, it's likely to be out of balance," Vitasek says. "You need to constantly re-evaluate the project to make sure that everything is in balance."
It's part of the project manager's job to do so. "When management asks a team to undertake a project, they don't necessarily think about what is needed to implement the project. The project team has to go back and spell out the people, time, and resources needed to get the job done," she says.
The right meetings. Managing meetings -- and making them productive -- is a critical part of project management.
There are a number of different types of meetings, Vitasek says. Some are work sessions where the nitty-gritty work of developing, evaluating, and selecting solutions gets done. The results of these work sessions, which may be held daily, are reported at core team meetings. During the team meetings, often held weekly, solutions are presented, progress evaluated against milestones, and barriers identified and addressed.
Core team members, headed by the project manager, then report to the executive sponsor or team, perhaps once a month or once a quarter.
For meetings to be most productive, it's important to establish a meeting culture where team members feel comfortable submitting barriers, Vitasek suggests.
Also work to establish a culture that emphasizes forward movement rather than endless discussions. Establish methods of dealing with less-than-expected results and unproductive behavior, such as work being done at what should be status meetings because teams haven't done their homework.
Six Steps to Success
Kate Vitasek identifies six phases of effective project management:
-
Phase 1 -- deciding whether or not to pursue a project -- involves "determining whether the project is sufficiently feasible and has a potential return significant enough to justify developing a detailed specification and business plan," Vitasek says.
-
Phase 2, project definition and planning, includes defining the project in a detailed statement of work (see Project Plan Outline, page 110), and developing a sound business case and plan for the project.
-
Phase 3, the execution stage, includes developing a detailed project plan and updating the business plan and statement of work.
-
Testing takes place during the critical fourth phase, with deliverables for this phase including the test plan and the test results.
-
Phase 5 is the go-live phase, when the project is launched.
-
The sixth phase, evaluation, involves assessing the project, comparing actual results to the project's original goals and objectives, reviewing results, and identifying and documenting lessons learned so that they can be incorporated in future initiatives.
"Most companies want to jump straight to Phases 3 and 5," Vitasek says. "If you skip or skimp on the other phases, however, you increase the likelihood of less-than-optimal results."
When Good Projects Go Bad
Stories abound of logistics change initiatives that fail to deliver anticipated results, that fall behind schedule or have ballooning expenses. Here are some reasons projects don't deliver:
Too many corporate initiatives. When companies are trying to transform themselves, "there's a risk of trying to change too many things at once," Bill Read says, even if a number of those initiatives are outside the logistics arena.
"There can be too many initiatives competing for corporate attention, because they all tap the same resources, whether it's dollars, executive attention, IT resources, or functional expertise."
Ineffective plan. "Projects get in trouble when there's no plan -- which should include a clear statement of objectives," Ben Gunter says. In addition to all the other problems caused by an inadequate plan, there's a good chance the project team won't understand senior management's priorities.
An inexperienced project team. "If the people responsible for implementing a complex project don't have the appropriate experience, it can hinder the project," Gunter says.
Experience at mid-manager level is critical. Inexperienced team members "don't know what to expect, don't know what key areas to watch, or what feels right and what doesn't."
If a company doesn't have available experienced people to serve on the project team, "it is senior management's responsibility to find a way to fill in the gaps," Gunter says. The solution may be a consultant, or a mentor coaching a team member who lacks the necessary experience.
Fuzzy roles and responsibilities. Each person's role on the project team has to be crystal-clear, Sisko says. "You cannot have split responsibilities -- one person has to have overall responsibility and authority."
Technology as the silver bullet. Some companies forget that technology is an enabling tool, rather than the end goal, Read says. "They forget what the overall case for change was, and the dimensions of change that have to occur."
In some cases, this may stem from the fact that the project is viewed as a software or computer project rather than as a logistics or supply chain initiative.
"The team might get caught up in the fun of the software and lose sight of why management is paying for the project," Gunter says. "Senior management doesn't buy a warehouse management system because they're in love with a WMS -- they buy it to achieve benefits such as reduced costs, improved customer service, and increased volume and productivity."
Reluctance to bring in another point of view. "Management teams leading complex programs tend to bring in folks they know to work on the project," Read notes.
While it's good to work with proven entities, doing so can limit creativity. "The best projects challenge themselves to profile the team and make sure they're bringing in varying perspectives" to get the optimal result.
Too many staff people, too few field practitioners. While it can be a challenge to free up key operations folks who have the responsibility for running the business, there's a real danger in having a project team loaded with staff people who may be more easily available to work on the project.
"You run the risk of not having the field team's ownership, and in having an implementation design that's not practical because it's not based in the real world," Read explains.
Conflicting contractors. "When there are a lot of contractors on the job, they can come into conflict," Sisko notes. The conflict may stem from something as simple as not having enough floor space to stage conveyors and racks at the same time, or one contractor having to clean up after another.
The more parties involved in a project, the greater the likelihood that conflict will occur at some point. "That's why it's important to establish a constructive atmosphere, with everyone working toward the common goal of getting the job done," Sisko says.
Yes, managing a complex logistics/supply chain initiative is a major challenge, with hard work, long hours, and potential problems. When it's done right, however, the blood, sweat and tears pay off in significant operational improvement and competitive advantage.