 | Level: Introductory Andrew M. Breen (markmi99@yahoo.com), Management Consultant, Project Manager, Independent
22 Apr 2008 Shorten timelines, lower implementation costs, improve deliverable
quality, and foster best practices by creating a logical road map that provides a
framework for development project decision making.
Advances in technology and software development have yielded powerful
productivity tools intended to help shape a better future. However, without a
well-planned blueprint to define the scope and business rules, prospects for a
successful project are dim. After all, even the most ingenious and elegant code
will be abandoned if it fails to deliver on key business goals in a timely and
cost-effective manner. Indeed, even successful projects eventually hit their
sunset as improvements become viable.
 |
Frequently used acronyms
-
IT: Information technology
-
CEO: Chief executive officer
-
CIO: Chief information officer
-
CTO: Chief technology officer
-
SME: Subject matter expert
|
|
Therefore, the central issue becomes how to most effectively manage business
change to provide the greatest value in the shortest amount of time. This article
outlines a structured approach for the project team to follow so that team members
can answer that question and, hence, improve the likelihood of success.
This article makes a few assumptions that you should be aware of:
-
Assumption 1: This article is primarily concerned with joint IT and
business projects. Although other areas such as construction, utilities, and
health care use similar principles, for the sake of clarity and simplicity, I
confine my discussion more narrowly. The sample project is the replacement of an
old general ledger system with a new one.
-
Assumption 2: Having defined the "universe" in assumption 1, I use the
second assumption to illustrate the power of the key concepts I discuss. The
recommendations provided herein apply to almost any possible project you could
conceive of. The more complex the undertaking, the more the principles are
needed. Therefore, I attempt to provide broad principles that are widely useful
rather than an industry best practice.
-
Assumption 3: This article assumes that the project has already been
selected or is near to selection. The article isn't designed to analyze which
project should be selected. That's something I will gladly cover in another
article. The purpose here is how best to bring the selected project to
completion.
This article is primarily directed at project decision makers: CEOs, CIOs, CTOs,
and senior program and project managers. Using the principles in the road map
presented here, you can expect to reduce development time, lower implementation
costs, and improve the quality of your deliverable.
The outline for this article is based on the hypothetical general ledger upgrade
mentioned earlier.
Plan the work
Assemble the right people
No matter what the technology or the nature of the endeavor, project work
succeeds or fails because of the people on the project team, how well they do
their jobs, and how well they communicate among themselves. Therefore, the
establishment and maintenance of proper roles and responsibilities simply cannot
be overemphasized. Here are some suggestions on defining roles:
-
Owners: They pay for the project and own the result.
-
Stakeholders: Changes brought about by the project affect their areas
of responsibility.
-
Project manager: The focal point for daily project responsibility, this
person plans, manages, and reports on the project to owners and stakeholders.
-
SMEs: These people are knowledge leaders in well-defined areas and are
typically involved with helping to define and shape project goals.
-
Project champion: A tie-breaker. When conflict arises between owners or
stakeholders, this person—typically a member of senior
management—is available to make a decision.
-
Others: It's usually a good idea to bring the human resources (HR)
representative into planning to select resources for the team and to redefine
job descriptions for the new environment. What is of vital importance, however,
is to understand the corporate culture and to facilitate change by removing
barriers caused by fear and ignorance.
Come to an agreement on the project's
goals, scope, and scope elements
Many of the individuals described previously will need to take an active role in
planning and implementing the project. Written agreement, in the form of a project
charter, will embody at least the following items and assign the project manager:
-
Select a project name: Select a name for the project—for
example, ERP_US.
-
Goals: Project goals are the major business drivers that the project
provides and the reason the project was selected. In this case, the goal is a
new general ledger system that will process faster, cheaper, and more accurately
than the old one.
-
Scope: The scope is a further breakdown of the project's goals into
cost, timelines, and major categories of deliverables that the project will
provide—for example, a US general ledger system that will cost
US$4,000,000 and that will integrate with the existing accounts receivable,
accounts payable, fixed assets, cash management, and budgeting and forecasting
systems. The project will be delivered in four phases and will be completed on 1
Aug 2008. An agreed-to scope minimizes unnecessary change.
-
Scope elements: This document is simply a further breakdown of the
scope into discrete deliverables—for example, a general ledger system
that possesses the throughput to handle 5,000,000 journal entry lines daily,
processes multiple currencies, consolidates differing accounting organizations,
and reports online and in print easily and flexibly. It's worth noting here that
the breakdown of the work goes even further than this. When decomposed to the
lowest level (for example, define consolidation models, test, and implement),
you have built the skeleton of the project plan (called the work breakdown
structure, or WBS) that will be used to manage the tasks, costs,
resources, and timeline used to guide and manage the project.
 |
Editorial note
I have seen more than one project that made the mistake of putting the cart
before the horse, so to speak. In other words, business drivers were either
ignored or put in a secondary position to technical requirements and
capabilities. In our hypothetical general ledger upgrade project, an example
would be IT procuring a more powerful machine than is called for—one
that doesn't run the software needed to meet the business requirements. Again,
this discussion should have taken place during the planning phase, as all major
requirements were.
Projects that make this mistake are inevitably late and over budget and do not
provide the necessary deliverables. Remember, the IT systems are the enablers for
bringing about the business changes requested and paid for by the project owner.
In an all-IT project, this departure might be less noticeable; otherwise, it
will cause unnecessary disruption of the organization's imperatives.
|
|
Come to an agreement on how the project
team defines success
Pre-implementation documents such as the project charter and the project scope
statement must clearly explain the who, what, when, where, why, how, and
how much it will cost to ensure that all key parties know their
responsibilities, deliverables, timelines, and so on. For instance:
-
Who: IT, finance, change management, and HR departments
-
What: Produce new general ledger system as defined in the scope
elements
-
When: Goes live 1 Aug 2008
-
Where: US locations only at this time (NY; Atlanta, Georgia; Charlotte,
North Carolina; and San Francisco, California)
-
Why: To implement ERP_US
-
How: Oracle ERP roll-out: US goes first
-
How much: US$4,000,000
This list also clarifies the scope and is used to manage scope creep.
Come to an agreement on testing,
sign-offs, and change-management processes
Okay, so you now have a project scope statement, a project charter, and a project
plan. At this stage, the first two documents should be final, and the plan should
be developed as far as is known, with placeholders to remind the project manager
to further define the plan as new details emerge. This is not an invitation to
change the scope. Rather, it's an opportunity to better define steps that had been
estimates before. For example, instead of handling six currencies, the new general
ledger must process eight.
At this point in the planning process, you need to cover testing, sign-offs, and
change-management practices:
-
Testing: You must define levels of testing (unit, integration,
conference room pilot) and what is to be tested at each level, and you must
explicitly spell out what constitutes acceptable and unacceptable results.
Prioritize and rework unacceptable results until they are acceptable for the
owner's sign-off. Test and agree to major transaction classes first, then do the
next important task, leaving the minor task for last. The earlier that testing
begins, the more test cycles are potentially available to run.
-
Change management: The idea of the scope statement was to limit changes
to the project. Changes usually require more time and cost and can cause you to
miss a deliverable or implementation date. Sometimes, change is required or
needed (for example, a new depreciation method of fixed assets is required that
will affect your accounting build-out and tax reporting). Again, the proper
sign-offs (as defined in the project charter or scope statement) must be
obtained to identify, approve, and manage the change.
 |
Work the plan
Acquire resources
Acquire resources with the skills you do not already have internally, and
match those resources to planned tasks.
Execute the plan
Fill in placeholders, and complete the plan to include
tasks, task dependencies, resources, costs, and time.
Report progress
Maintain progress reporting, including daily measurements of actual versus
planned change (per the project plan)—for example, Task 100: Define
Chart of Accounts. A. Breen is 60 percent complete versus 50 percent called
for in the plan. No issue here. Escalate as appropriate. Milestone-related
tasks are rolled into hierarchies and reported to senior management for analysis
and action.
Assign issues
Assign issues to owners for action or closure in a timely manner.
Road map checklist
Use the following checklist to create your own development requirements road map.
Checklist
Plan the work
| Checklist | Notes |
|---|
|
1. Assemble the right people.
| ___________________________ |
|---|
| Owners | ___________________________ |
|---|
| Stakeholders | ___________________________ |
|---|
| Project manager | ___________________________ |
|---|
| SMEs | ___________________________ |
|---|
| Project champion | ___________________________ |
|---|
| Other—HR | ___________________________ |
|---|
|
2. Define project components.
| ___________________________ |
|---|
| Select project name. | ___________________________ |
|---|
| Agree to project goals. | ___________________________ |
|---|
| Agree to project scope. | ___________________________ |
|---|
| Agree to project scope elements. | ___________________________ |
|---|
|
3. Come to an agreement on how the team defines success.
| ___________________________ |
|---|
| Who is assigned to the project? | ___________________________ |
|---|
| What is the purpose of the project? | ___________________________ |
|---|
| When do we implement? | ___________________________ |
|---|
| Where is the work being done? | ___________________________ |
|---|
| Why is the project being done? | ___________________________ |
|---|
| How is the project to be delivered? | ___________________________ |
|---|
| How much does it cost? | ___________________________ |
|---|
|
4. Project controls
| ___________________________ |
|---|
| Testing | ___________________________ |
|---|
| Change management | ___________________________ |
|---|
| Sign-offs | ___________________________ |
|---|
Work the plan
| Checklist | Notes |
|---|
| 1. Acquire all resources needed. | ___________________________ |
|---|
| 2. Update, complete, and execute the project plan. | ___________________________ |
|---|
| 3. Report periodic progress. | ___________________________ |
|---|
| 4. Assign issues, and escalate as needed to close. | ___________________________ |
|---|
Conclusion
This article showed that there are a relatively small number of project
management concepts and practices that, when used effectively, have a powerful
effect on reducing project cost (for example, by doing things right the first time
with sufficient planning), saving time and expense, and producing the desired
change. Using the road map provided in this article, you can step through your
next development project with ease and success.
Resources Learn
Get products and technologies
- Download
IBM
product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli, and WebSphere®.
Discuss
About the author  | |  | Andrew Breen was born in New York City and raised in Westchester County, N.Y. He
earned his BS degree in experimental psychology at Syracuse University and his MBA
in finance at Pace University. He has worked for IBM and Cap Gemini Ernst
& Young. |
Rate this page
|  |