A Guide To Project Management v
A GUIDE TO
PROJECT
A Guide to Project Management
Introduction
This document is a guide to project management techniques that Arkieva has found useful for managing the development of Decision Support Systems. The suggestions here are not intended to be unbending rules. These guidelines mainly apply to the projects that are initiated directly and managed by Arkieva; parts of the document have broader application.
Initial Contact with the Business Unit
Typically the business unit has the following fairly common needs:
Let your business contact know the steps involved in building a decision support system: 1. Scoping session
2. Scope of work document 3. System
4. Gathering and committing resources 5. Training
6. Documentation 7. Maintenance
8. Measuring and reporting results Let them also know about our methodology:
Too much or not the right type of inventory Too few inventory turns per year
Customer service problems; unable to manufacture and ship the right products in the right amount and time
The scheduling expert is ready to transfer, retire Insufficient production capacity
The business was scheduled manually or with spreadsheets but now the scheduling has grown too complicated and more sophisticated tools are needed
Build a system to help the person do the job Integration of systems, technology, and people Prototyping with short development cycles
A Guide To Project Management 3 v
1) Scoping Session
The goal of this session is to gather all of the information needed to write the first draft of the project plan. This session should take no more than a day.
The information from this meeting will be used to develop a “scope of work” document.
The following people should be at the meeting; usually one person may fill more than a single role:
Publish a meeting agenda before the meeting. The agenda should have a meeting purpose, and a description of each of the items that you want to cover.
Interview from the top down (big picture first) and avoid getting lost in the fine detail. Remember you are after the high-level road, not all of the details. You should read the project templates and use this meeting to fill in the details.
Questions to ask during the scoping session:
Arkieva Member(s) Business Manager Manufacturing Manager Capacity Planner Production Planner Production Scheduler
Business data systems representative
Manufacturing data systems representatives
What is the scope of the system or business deliverable/release (both with respect to time and with respect to the number of steps along the supply chain)?
Will the planning be in hourly, daily, weekly, monthly, and/or yearly time buckets?
Will the system include forecasting, distribution requirements planning, multi-plant scheduling, multistep production scheduling, and/or raw material ordering?
What other systems exist which might overlap this project or which will interface with this
project?
This data will include forecasts, hard orders, production recipes, machine constraints, production rates, yields, changeover times, hard and soft rules, etc. Hard rules mean rules which must never be violated. Soft rules mean rules of preference. Be sure you question the business about hard rules; often we find that hard rules may be soft rules. They are thought to be hard only because "we always have done it this way. “
Topics to consider during the scoping session:
What is the stake for the project?
Will inventories be lowered?
Will production capacity increase?
Will customer service improve?
Will important knowledge be captured?
Who is the management sponsor for the system?
Who signs the checks and are they on board?
Who opposes the development of the PP&S system and why?
Who strongly supports the development of the PP&S system and why?
What other projects are competing for resources?
Are there any hardware and/or software restrictions?
Is all the necessary data online in other computer systems?
Communicate the required participation from the client. Each role is not a full time position, and one
person may fill multiple roles
A primary point of contact to act as Project Manager or business unit representative. This person will
serve as the interface between the client’s upper management and Arkieva. They will be responsible for providing ongoing project direction and priorities, and will conduct periodic review meetings.
The client will provide an experienced plant representative to serve as Data Coordinator. This person's
A Guide To Project Management 5 v
2) Scope of Work Document
The Scope of Work (or project plan) is a high-level road map by which the system will be built. You can expect to spend two to four days developing the project plan. The following elements might be included in the project plan:
Purpose of the System
This should be a clear high-level statement of the purpose of the project. Examples may include:
Business benefits
The client will provide at least one full time, hands-on model developer. Arkieva will help this person
develop MIMI modeling skills, and the ability to develop user interfaces and reports.
The client will provide a Systems Support person. This person will be responsible for generating extracts
from existing applications and move them to the MIMI computer, moving flat files generated by MIMI to other client applications, and provide network support and central systems support.
The client will provide a Systems Support person. This person will be responsible for generating extracts
from existing applications and move them to the MIMI computer, moving flat files generated by MIMI to other client applications, and provide network support and central systems support.
The client will provide end users to assist in model development and validation for the tools that they will
be using. This typically will require an average of 50% of their time for the development cycle for their
area. Their involvement will be more intensive that normal because of the amount of data collection and data validation that will be required.
Define a feasible way of getting cases to the client and back, i.e. telnet, mail, Fed Ex etc.
Finish the meeting with a benefits and concerns. ALWAYS do benefits first because it helps to focus
people on the positives.
The purpose of the PP&S system is to synchronize the production of finished goods at plant x with the semi-finished production at plant y.
The purpose of the DM model is to consolidate customer demand and provide a framework for capturing market information
The PP&S system is a set of tools which will be used to schedule the acquisition of raw materials, chemical and physical transformations of materials inside the plant, and the movement of materials in the plant.
The system will make it easier to balance the following often-conflicting goals: shipping all orders on time, keeping inventories low, and making effective use of facilities and people.
What business benefits will the business unit see after the system is in routine use that they didn't see before the system was built? Examples may include:
The purpose and the benefits should be included in the executive summary. If possible give dollar values for the expected benefits.
3) System
How does the system fit into supply chain management? Show the current planning process in a generic way. Show how demand comes in and is used in planning. Modify the “wiring diagram” as appropriate, and identify the functions on the diagram that are within the scope of the system. Scope questions include:
Reduced Inventory
Shorter manufacturing times Higher turnover rates
Increased production capacity
Capture of scheduling knowledge in the system
Smooth flow of information and martials along the supply chain Improved speed and quality of decision making
Lowered total (raw materials + in-process + finished-product) inventory level
Ability to see problems days and weeks in advance and make changes in supply, demand, and the schedule to minimize the impact of the problem
Better manage the business by taking a holistic (high-level) view of the entire operation and see the impacts of a local decision on the whole
Able to give accurate raw material needs to suppliers weeks in advance
Improved cooperation and communication between marketing, sales, customer service, and manufacturing
Better able to ship on requested ship date
Quickly answer what-if questions from customer service regarding the ability to accommodate a change in demand (different ship date, different amount, new order, or canceled order)
A Guide To Project Management 7 v
Rapid Constructive Prototyping (RCP) Methodology
The Supply Chain uses rapid constructive prototyping (RCP) with incremental deliverables. At the end of each prototyping iteration a process check is made to see whether the team is progressing toward the goals and appropriate corrections made.
RCP development can be reviewed as a series of prototyping cycles in which the goals are reached by successive approximation. The development team works their way up a learning curve and the system documents their progress up the learning curve.
The RCP methodology must be managed differently than the development of traditional computer systems in that less structure is needed to allow for the necessary experimentation and creativity.
Arkieva has learned that either too little structure or too much structure can cause a project to fail. The optimum is a semi-structured approach to project management.
What will the system actually do in operational terms?
List what the system will do and describe several typical daily scenarios that relate how the system will be used to support decision-making.
What will the system not do?
What is the scope of the system?
Will it include one plane or multiple plants? Will it include just a portion of a plant?
Will it include forecasting, distribution requirements planning, production planning, production scheduling, and/or raw material ordering?
Compute a cost for each schedule Automatically order raw materials Automatically order shipping containers Automatically issue shipping papers
Generate a schedule without any human input On-plant inventory tracking
Will the PP&S system "optimize" the schedule?
The word "optimize" in a scheduling context means different things to different people. It's best to make a clear statement about the system's ability to optimize, what optimize means, what function or measurable are to be optimized, etc.
To what extent will the system be automatic? One area where there is the potential for considerable
misunderstanding is the extent to which the PP&S system will be automatic. At one end of the spectrum we have totally manual scheduling that has a lot of human input and at the other end we have pushbutton automatic scheduling that has no human input.
PP&S systems operate in semi-automatic mode with some of the work done by computer and some of the work done by humans. Human input is needed for what-if analyses, insight, intuition, politics, etc. At best we expect to be 80% of the totally-manual extreme to the totally-automatic extreme.
Who are the members of the development team? What is the responsibility of each member? What is their time commitment?
Go through each of the team members and list their names, responsibilities, time commitment, and primary location where they will work on their part of the project. Identify the ultimate users of the system. Here are some suggestions for the responsibilities of the team members:
Writing the project plan
The overall health of the project
Monitoring the expenditures and progress against the project budget and timeline
The Developer and Co-Developer are the people who build the system. They are responsible for taking the collective vision of the team members and turning it into computer code, databases, etc. The Co-Developer is also the maintainer of the system.
The Business Manager and the Manufacturing Manager are the sponsors for the project. They review the progress and sign the checks. They are responsible for seeing that the systems meet business and manufacturing needs.
The Business Information Systems Representative and Manufacturing Information Systems
Representative are responsible for finding the necessary data in existing computer systems and writing (or causing to have written) the program to extract this data into flat files.
The Capacity Planner, Production Planner, and Production Scheduler are responsible for the planning scheduling logic for long time (years), intermediate time (months), and short time (days, hours), respectively.
A Guide To Project Management 9 v
Keeping the project on time and on budget Managing user expectations
Assembling the resources needed to build the system Reporting incremental progress to management Calling milestone review meetings
Resolving personnel issues
Handling/resolving any requests for a change in project scope
What are the major components of the system?
Either write a paragraph description of each component (What will each cost to build? How long will each take, man-months and elapsed time, to build?) or put together a high level task list with the same information.
What are the task timelines and milestones for the project?
Optional.
What does a 100% time commitment mean?
For estimating purposes we figure that there are 12 holidays per year, 15 days of vacation, 4 sick days, 52 Saturdays, 52 Sundays, and one day per week spent with unbillable activities such as staff meetings, Review meetings, conferences, office moves, committees, retreats, etc.
That means that each person is available to work on billable projects for 365-12-15-4-52-52=178 days per year or fifteen days per month. Therefore 100% on a project means fifteen 8-hour days per month (120 hours) effort on the project. 0% = 0 days 20% = 3 days 50% = 7.5 days 80% = 12 days 100% = 15 days Hardware
If hardware must be purchased for the project, state each item and how much it costs to lease or buy. Also state maintenance contract costs and the cost of updating the operating system (if a computer).
Software
If MIMI must be licensed, please state the item and its licensing and maintenance costs.
Data Transfer Costs
computers. There are data transfer costs associated with the gathering of this data onto the computer used for scheduling.
Circulate the Project Plan for Modification/Updates
All key players should get copies of the project plan and should be asked for their comments and upgrades. Typically you can expect to go through 1 to 2 iterations before the project plan converges and is approved. 4) Gathering and Committing Resources
Once you have approval to go ahead with the project it is time to gather the resources from within Arkieva and the business unit to develop the project.
Project Tracking Meetings
Four types of project tracking meetings are needed:
The new functionality is demonstrated and discussed
The financial information (savings, increased earnings, and expenditures) is reported Each member has the opportunity to propose a change in the project plan
Maintenance of the new functionality is turned over to the business The team discusses whether to continue as planned
Completely new items should be thrown in a bucket list
What to do when a project is significantly off-track?
Bring the entire project team together:
(Daily) meetings between developers: Developers will typically have frequent conversations to make sure that their work is not overlapping, help each other solve design problems, etc. These are generally informal.
(Weekly) project manager meetings: The Project Managers will typically meet for an hour or so each week to discuss any problems that have surfaced that week and work our plan to resolve the
problems. Other team members will attend these meetings as needed. (OPTIONAL)
Tracking meetings at fractions of the way to a milestone: Developers, project managers, and key users meet to review their progress toward the milestone and determine if the progress is close to (or far away from) the task timeline. If far away, then use the suggestions in Section VIII below. Tracking meetings might be held at perhaps 25%, 50%, and 75% of the way toward the milestone.
Milestone meetings: At major milestones the entire development team is called together and the following are covered:
A Guide To Project Management 11 v
After the project managers revise the plan, the project plan is circulated to the entire project team for approval.
Scope Control
It is not uncommon for someone to propose a change in project scope; either a narrower scope or (more likely) an increase in scope. If both Co-Project managers agree to seriously consider this proposal, they should prepare a short one or two page description of the additional work. This new plan should be circulated for comments and approval.
Under no circumstances should the Co-Project managers agree to substantial change in project scope without revising and circulating the project plan because there is too much opportunity for misunderstanding.
What to do when personality/ego conflicts arise?
The Co-project managers should meet with the conflicting parties apart as well as together and seek a better understanding of the nature and reasons for the conflict. In some cases where different personality types are in conflict the persons may achieve better understanding through participation in courses.
What to do when a key player departs?
Sometimes a key player becomes unavailable from transfer, illness, leaving the company, re-prioritizing their time, etc. This is one of the most disruptive things that can happen to a project. It invariably leads to a loss of momentum and sometimes can make the project stall. There is no way to prevent some disruption, but the best thing to do is to call a meeting of the entire development team, present the problem, and as a group rearrange priorities and roles to fill the gap.
Later another person may join team to replace the person who has left; the Co-Developers should design an education program to bring the new person up to speed.
5) Training
A training plan for the Co-Developer and users of the system should be laid out in detail. What courses will they take? When and where will they take them? What on-the-job training is needed?
6) Documentation
Cases should be well-documented in order to make them maintainable. Each client has its own standards for documenting the system. Arkieva should use the standard libraries and skeleton macros to document the model. Use of DMDOC as a cross-reference is highly encouraged.
7) Maintenance
Is it agreed that there is a problem? Does everyone understand the problem? What are the ramifications of the problem? Should the project plan be revised? How?
Once the system is in production, its maintenance is critical for sustainability. If the system is not easily maintained, then it will not be supported over a long period of time. Consider the following ways to make a system more maintainable:
8) Measuring and reporting results
When the project plan was developed, the business described the goals for the system. This could be improved customer service, lowered inventories, increased capacity, etc. The goals should be translated into a measure made at the start of the project. After the system is in routine use for several months, the measurements should be reported to the entire development team.
Project File
Consultants should prepare and maintain a central file which contains:
A one page description of the Project scope, contact persons, and expectations. Example: Good documentation.
Place all parameters in tables and make the program table-driven. Changes to the model then become
table-editing rather than programming.
When the developers finish the system, they will know what is needed to maintain the system. This
knowledge can be expressed in the form of rules and algorithms. Build an expert system, which handles most of the routine maintenance.
Wherever possible use robust techniques. This includes such things as validity checking of user input,
batch jobs that detect errors and resubmit jobs or notify maintainers when there is a problem, file locking to prevent user collisions, etc. Arkieva has extensive experience in making systems robust. Never develop a system that requires another module to work perfectly before this module can work. Each module should be able to handle incomplete data.
A Guide To Project Management 13 v
The project plan as outlined in this document All official correspondence
A description of how to get cases back and forth from the client
User names/passwords at the client site; how to log in when at the client site Names of cases, and the directory at Arkieva
