Skip to main content

skip to main content

developerWorks  >  Architecture  >

Development requirements road map: It's the planning that counts

A framework for successfully managing change

developerWorks
Document options
PDF format - Fits A4 and Letter

PDF - Fits A4 and Letter
27KB (8 pages)

Get Adobe® Reader®

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


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.


Back to top


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.



Back to top


Road map checklist

Use the following checklist to create your own development requirements road map.


Checklist
Plan the work
ChecklistNotes
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
ChecklistNotes
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.___________________________


Back to top


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


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top