4. The Right Resources
Aren’t Assigned or Available
It’s difficult to participate in a project and also do your
regular job. It sometimes seems that a few people in the organization are asked
to do everything. Be realistic when assigning people to different project
responsibilities and allocating their time, and recognize when external skills
would be more efficient even though the cost might be higher. For example,
hiring resources for the upgrade to R12 may seem more expensive than having
your DBA try to do it internally, but consultants who perform upgrades
day-after-day develop a variety of “lessons-learned” and ways to streamline the
process. Additionally, it does not make sense to have your internal DBA spend
months on learning to do something that he or she will never need to do again.
The time could be better spent on other projects.
5. No Project Champion
Few complex, large-scale Oracle projects are ever successfully
completed without someone in the C-suite or other high-level position endorsing
and prioritizing the project and its outcomes for the business. Your executive
sponsor is critical in ensuring that other lines of business and cross-departmental
resources are made available and prioritized to successfully plan, manage, and
complete your project.
This is particularly important for IT projects, where
dependencies across business units can make or break both the success of the
project as well as how quickly and efficiently it can be managed and
implemented. IT can initiate many different projects, but without the support
of the business they won’t be successful. A project champion can help
prioritize projects based on the business needs and then promote the successes
within the organization, both in terms of measurable results and in obtaining
buy-in from different parts of the organization.
6. Scope is
Inappropriate
Many ambitious project managers try to bite off more than they
can chew. For example, it’s often much easier to test and verify a single ERP
vs. multiple areas at once. It’s probably not the best idea to change operating
systems, upgrade to R12, and change your chart of accounts all at the same
time. You are shooting at a moving target that introduces a lot of instability
with each of the processes. Isolate changes so that they can be tested
individually and the users can understand the impact of one change before the
next one is implemented.
Break up your project into smaller projects (try for projects
that can be completed in 4-6 months, especially early on) to get success and
demonstrate momentum. Those early wins can often gain additional credibility
and resources to tackle bigger chunks of the entire project. Long projects lose
momentum, delays occur because of changing priorities, the requirements change,
budgets get cut, and resources are reassigned to the next project or leave the
organization, so costs increase.
7. Poor or
Inappropriate Metrics
If you know the outcome you’re seeking, you should also be able
to define it. And if you can’t define success based on a single or small set of
key metrics, it will be difficult not only to “sell” the projects internally to
those who will approve budget and resources, but also to communicate success
and completion at the end of the project.
Appropriate metrics include benchmarks and baselines for where
you’re starting, in addition to success metrics at the end and key milestones
along the way. Use all three of these metrics (baselines, milestones, and
completion metrics) to make your case up-front and rally budget, resource, and
executive support.
Specific metrics to focus on include return on investment (ROI),
cost savings, and resource reductions. Include reduction in the number of staff
or time required for a particular operation (like reducing closing time from 8
days to 3 days, or days sales outstanding from 20 days to 9 days, etc.) and
reduction the number and complexity of spreadsheets required. Tie the project
to metrics identifying cost savings. As you communicate metrics at various
stages of the project, leverage a communication plan created up-front that
details who needs to know what, the levels, channels, and frequency of project
update communication, etc.
No comments:
Post a Comment