question archive Published in Proceedings of the 13th Annual Symposium of the International Council on Systems Engineering, Arlington, VA, June-July 2003

Published in Proceedings of the 13th Annual Symposium of the International Council on Systems Engineering, Arlington, VA, June-July 2003

Subject:BusinessPrice: Bought3

Published in Proceedings of the 13th Annual Symposium of the International Council on Systems Engineering, Arlington, VA, June-July 2003.

Process Implementation

Sarah A. Sheard

Software Productivity Consortium

Herndon, VA 20170 www.software.org

sheard@software.org (703) 742-7106

Abstract. Process improvement requires two major steps. First, new processes must be defined (or existing processes modi?fied). Second, the organization must begin to use those new or changed process descrip?tions. The literature has provided good guidance on writing new process descriptions, but very little has stated clearly what actions must be taken to implement and then institutionalize the use of the processes. This paper pro?vides a list of implementation and insti?tu?tionalization actions that organiza?tions should consider to ensure that the new processes are used. These actions fall into the categories of train?ing, ensur?ing management support, obtaining a meas?urement baseline, audit?ing the use of the processes, collecting and main?taining a library of process assets, tai?loring the pro?cesses, improving the pro?ces?ses, and appraising the organiza?tion.

Introduction

Writing new process descriptions may turn out to be the easy part of process improve?ment. This can be a very depressing thought to those who spend years in pro?cess improve?ment groups such as process action teams (PATs) or systems- or soft?ware-engi?neer?ing process groups (SEPGs). Sometimes the “light at the end of the tunnel” seems to be publication of an inte?grated set of descriptions of improved processes. However, once those processes are defined, documented, and even com?mu?nicated, much work remains.

In order for improvement to happen according to these new process descrip?tions, each person working in the imple?mentation organization will need to do the following:

· Access the process descriptions

· Understand all the processes at a top level

· Understand in detail the processes that he or she performs

In addition, managers must do the fol?low?ing:

· Understand all the processes at a top level

· Understand the project management pro?cess(es) in detail

· Understand how to manage the organi?zation using processes

· Access historical measurement data for all processes

· Support implementation of new pro?cesses in their own work

· Remove roadblocks to implementation

The steps outlined in the next sections include those activities needed to establish the environment for process implementa?tion, ongoing process maintenance tasks that need to persist, and specific one-time implementation tasks that initiate the use of new processes. These steps assume that a sponsor, steering committee, SEPG, and PATs already have been chartered and operating for some time, but that their roles will be changing.

1. Manage Process Implementation as a Project

Nearly all good process improvement advice emphasizes that process improve?ment must be run like a project, with a project manager, plan, resources, and the other essentials for any project. This in?cludes having a good plan and tailoring a set of process descriptions for the imple?mentation project. Activities include the following:

1) Create Implementation Plan. The organization must create a process improvement implementation plan that includes the tasks in this list, an appro?priate time frame for each, and the resources needed. Tailor the organiza?tion’s project management pro?cess to apply to the process group’s project for implementing processes. (If this pro?cess is unusable, that is a good signal that it needs to be improved first.) Be sure to identify and mitigate imple?mentation risks. Follow the plan in implementing pro?ces?ses. Periodically revisit the plan and make adjustments as needed.

2) Track Progress. In addition, the pro?cess improvement group must track the progress of the process improvement effort against that plan. Are the planned resources being provided? Are training courses and audits being held?

Not only is tracking required to keep the project moving toward its goals, but new appraisal requirements [CMMI 2001] designate the organi?zation’s own assessment of its imple?mentation progress is an important input into a Capability Maturity Model -Integrated (CMMI®) appraisal.

2. Obtain All Levels of Management Support

Ensure that managers support process use. As described in [Sheard 2001], senior man?age?ment commitment can make or break any change effort. One very impor?tant set of senior management actions is to ensure that middle managers also support the process improve?ment effort. Too often it is the many layers of program and line managers between prac?ti?tioners and spon?sors who sabotage the use of new pro?cesses. Activities include the following:

3) Plan Management Support. Deter?mine how you will be able to tell whether man?age?rs support process use (e.g., employee surveys, interviews, measures, other indica?tors such as requiring certain items in program status reviews and verifying that they are there and correct, and whether managers acknowledge process use to each other). What is the connection between managers fully supporting process use and their performance plans?

4) Identify Projects and Managers. Deter?mine who all the project mana?gers are. Show them the benefits of process improvement. Verify that they are following the project management process, including detailed planning and scheduling. (In the long run, this is a Quality Assurance (QA) duty, but the SEPG may need to provide the initial driving force.)

5) Define Resource Tracking Require?ments. Define requirements for a way to account for who has been assigned to do what tasks on projects, programs, segments, and other efforts. Often this will be a resource database.

6) Create the Resource Tracking Mech?anism. Be sure that your project management process description states how to allocate people to a project and how to un-allocate them when they leave the project.

7) Ensure That Managers Use the Re?source Tracking Mechanism. Make sure that managers use the resource database or other tracking mechanism, and that everyone on their projects is so noted in the database.

8) Verify That the Data is Correct. Peri??odically check that actual jobs match what it says in the resource tracking mechanism and that people are not over-committed.

3. Establish Policy

Organizations have policies and proce?dures in order to perform day-to-day business. This does not mean that the published policies are the same as the “de facto” policies actually carried out; often they are not. Nevertheless, it is important to set the expectation that indi??vi?duals and projects throughout the organization will understand and follow the new processes. This lends legitimacy to the processes and helps ensure their implementation. Activi?ties include the following:

9) Establish and Publish Policy. Esta?blish policy for following the organi?zation’s processes. (The policy will be written and approved earlier, but imple??mentation is when the policy is tested.). The sponsor setting the policy should know what docu?ments and other artifacts people will have if they do follow the processes (for example, they will have work plans, trade study reports, and configuration status reports), and should ask for them periodically, using the terminology from the process descriptions.

10) Take Action When Policy Is Evaded. Determine how you will be able to tell whe?ther the policy is being followed and what actions you will take if it is not. Taking those actions quickly and visibly the first few times that policy is evaded will go a long way toward promoting policy use in the future.

4. Establish a Measurement Baseline

Establish a measurement baseline that records how much effort current pro?cesses take to enact. Many companies, particularly those at lower maturity levels, do not know how much effort their current processes take to perform. They know how many people they have in the organization but not necessarily how many projects are being worked at any one time. While they may be able to find out how many staff months any given project took from one milestone to another, based on time charge records, they do not know how much of that time was spent on management vs. technical vs. support efforts, or on require?ments vs. design vs. rework. Do your best to find out what is known, and estimate the rest so that improvements due to new pro?cesses can be quantified. Activities include the fol?lowing:

11) Train in Recording Time. If neces?sary, determine a way for people to record how they spend their time, then train people in recording time.

12) Decide How to Charge Work by Pro?cess. Determine how you want people to subdivide their time charged (e.g., processes, activities, or work breakdown structure (WBS) elements). You should be able to use project man?agement artifacts to begin this effort, such as plans and WBSs. Test that these categories are usable and that people will not have to put a majority of their hours into “Other.” (Even though contractors have established ways of recording time, they do not necessarily have the flexibility to modify the charge numbers to allow record?ing of process-related activities such as “peer review meeting” or “requirements rework.”)

Set Up Tools to Use the Time-Charg?ing Scheme. Incorporate the things you want to measure into the tools for recording and analyzing time charges.

Plan Measurement. Plan what you will do with the data when you get it?how you will do all the steps below. Make analysis templates (e.g., test with simulated data). Do they meet the needs you have for the informa?tion? [PSM 2001] provides excellent guidance on measurement templates.

13) Estimate Breakout of Previous Actuals. Analyze one or more previ?ous projects. Determine how many people worked how many hours, dur?ing what months. Estimate the time they might have allocated to processes broken out the way you have broken out the new processes. While you know the breakouts will be inexact, the estimated subtotals should add up to the actual totals. Develop a baseline historical estimate for how much these projects charged, broken into the cate?gories for the new projects.

14) Validate Time-Charge Data. After and possibly before implementing new proces?ses, collect the time-charging data. Validate the data (e.g., are the hours recorded cor?rect?ly and are the categories understood?). Investigate data points that fall outside the expec?ted ranges (which you have determined in advance), and correct input data that was in error. Store it. Analyze it. Re?port on it. Decide what you want to do with it; for example, change how the data is analyzed or collected.

5. Train Employees and Managers

All employees and managers must under?stand the new processes. Process training is dif?fer?ent from domain-based training, such as use of a tool, a programming lan?guage, or a requirements capture method. This training introduces the processes to the organization in a manner that is effi?cient for those who are being trained. In other words, the training highlights differ?ences in the new processes from what is currently done today and, to the extent possible, is tailored for the specific audi?ence receiving the training. Activities include the following:

15) Communicate Process Improvement Goals and Products. Initiate commu?ni?cation, using multiple methods, about the process improvement effort’s goals, status, pro?ducts, and plans. Con?sider posters, newsletter articles, and giveaways like mugs, chocolate bars with special wrappers, or mouse pads. Also consider electronic notifi?ca?tion. The goal is to get everyone aware of the process improvement goals and their role in the effort, and let them know where to find the information they need.

16) Train Process Group. The process group should first ensure that they them?selves are trained before the imple?mentation phase begins. The process group members must do the following:

· Learn how to implement. The pro?cess team may not be expert in any process imple?mentation steps. They may need to attend courses or be tutored by imple?men?tation con?sultants. They will then need to provide feedback on the imple?mentation plan.

· Learn how to teach adult learners. Lecturing is neither the only nor the best way of teaching. Anyone providing training needs to under?stand the power of ques?tions, examples, exercises, and appli?cation to real-life situations. There are classes on how to teach; there are also good literature and Internet resources.

· Include alternatives to “sitting in a classroom while someone lec?tures.” Trainers should be able to provide different styles of training including teaching, mentor?ing, referral to hard-copy or online resources, and even training as a part of audits.

17) Develop Training Success Criteria. Develop success criteria for general process training. How will you know the training has been effective?

Training should include an intro?duc?tion to the capability model used, why it was selected, and how it is being used, but most employees should not receive more than one hour of focus on a model. Training goals for the different organizational roles are as follows:

· Managers must know why the organi?zation is using the model, what they will get out of it, and when (e.g., not right now).

· The general employee public should be trained on which model is being used and why, but they do not need to be given detailed infor?mation about the process areas of the model. Rather, the general employee public should be trained in the proces?ses they have to fol?low in order to do their work. Leave interfacing with the model to the process improvement group. This insulates the company from thrash?ing when models change, and it saves much training time and possibly much confusion that results when trying to train a large number of people on something that they see as irrelevant to their work.

· The appraised organization should get general training about an up?coming apprai?sal. This should be within the last few months before the appraisal and should state what is going on, why, what appraisers will ask interviewees, what inter?viewees should say (the truth), what employees should know in advance (your processes), and when to raise concerns (in advance of the appraisal).

18) Develop Waiver Criteria. Develop waiver criteria and procedure. How can you tell if someone does not need to attend training (e.g., quiz, self-selected, or manager says?). What if the processes are new? Ask whether the employee has the informa?tion needed to carry out the process.

19) List Potential Trainees. Find out how many people there are who may need to be trained, their names, their roles (and therefore which processes they need to know in detail). Determine what training or waivers they will need.

20) Obtain Funding. Obtain sufficient fund?ing to develop, pilot, and perform the training (including hours for the trainer and trainees).

21) Develop Training. Develop the train?ing material, including any quizzes or other instrument needed to show that the training had the desired effect.

In order to create good training material, the process group needs to take a close look at how the set of process descriptions will be used. Although the process devel?opers most likely have done this for their indivi?dual process descriptions, the users will see them as a whole set. In what circumstances will people turn to “the process manual”? What questions will they be asking? How will they navi?gate the set of pro?cess assets to find the help they need? When do you want to trigger people to revisit the process descriptions (e.g., on a peri?odic basis such as monthly, on an event-driven basis such as prior to scheduled review meetings or upon assignment of a trade study, or both)? Fold the answers into your training.

22) Pilot Training and Improve. Pilot the training and the quizzes (if any), and improve them based on feedback from the pilot offering.

23) Plan Training Delivery. Will this be project by project, process by process, broad?cast, Web-based and check off when you have finished, or what? It is often best to provide training just-in-time, so that people do not have too much to learn and will not forget by the time they perform the task on which they are being trained. This requires tradeoffs, such as how many different classes will be developed, and needing to remind people of the big picture each time you are discus?sing a single phase in detail; therefore, this must be worked out in your plan.

24) Train. Schedule the training, and ensure that the people who should be there will be there. Get project and individual agreement that the people will take the training. Provide the training. Grade tests and give credit to those who have learned the mater?ial successfully.

25) Reschedule. Reschedule training for those who do not sign up or do not attend.

26) Maintain Training. Evaluate when changes should be made to the training (either the training does not do the job, or the processes being trained have changed). Plan what “regression train?ing” needs to be done to get everyone up to speed with changes. Ensure that it happens.

27) Provide Ongoing Training. Continue to provide training to new employees and to those who are taking on dif?fer?ent job responsibilities so they need different detailed training. Provide refresher training in response to audit actions suggesting that people have forgotten aspects of the processes.

6. Tailor Processes

In order for the organization to imple?ment its processes, they must be tailored to the specific use intended by the projects. Depen?ding on the content of your process descrip?tions, tailoring may consist of removing activities that are only suitable for larger projects, selecting one set of activities from a choice of sets, turning a list of activities into a project plan (inclu?ding dates and names of responsible parties), or even filling out a matrix of prac?tice identifiers and indicating satisfac?tion. Activities include the following:

28) Mentor Projects in Tailoring Pro?cesses. Assign one or two process people to each project (or other effort requiring a work plan), to help the project use your tailoring guidelines to tailor the processes for their project. Escort the tailored processes through the prescribed approval cycles. This may include one-on-one meetings between the SEPG and managers to ensure buy-in.

29) Improve Tailoring Guidelines. Im?prove the tailoring guidelines based on measure?ments of how well the pro?jects understand them and how easy the pro?cesses are to use.

7. Maintain Process Assets

Your process assets, as well as their elec?tronic repository, are the nervous system of your organizational processes. They must be quick to react but not over-reac?tive. They must be current and usable. They must be maintained constantly, in addition to any upgrades that occur in a spike prior to an appraisal. Activities include the following:

30) Establish Place to Store Processes and Changes. Determine where you will store process assets as they are created. In general, you will need to adapt your process architecture to serve as a guideline for storing and later finding process assets. Make it as easy as possible for users to navigate among interfacing processes.

Consider that each process will have an official organizational version, project tailored versions, possibly a previous organizational version that earlier projects are working to, one or more new pilot versions, and potenti?ally one or more working copies being modified. Do not forget to make a place for process change requests, including blank, submitted but not yet reviewed, reviewed but not yet enacted, and final.

31) Determine Goodness Measures for PAL. Determine how you will mea?sure good?ness of the process asset library (PAL), such as usage numbers, audits, and user satis?fac?tion surveys.

32) Store Process Assets. As process assets are created and approved, upload them, creating the necessary indexing or other links for usability.

33) Track Tailoring and Examples. Track which projects are creating tai?lored versions and how extensive that tailoring is. Track which projects are creating example arti?facts (if appli?cable), and encourage others to contri?bute as well.

34) Track Repository Usage and Cur?rency. Periodically review the PAL or other repo?sitory for process infor?mation, both how well it is being used, how organized it is, and how current it is (e.g., are obsolete copies in use?). Track repository usage. How many people are reading or downloading what assets? When does this happen in the project (e.g., every phase or only before an appraisal)? Which projects—a few or all? Respond to needed changes.

35) Provide Help Desk. Provide help desk services for users having PAL prob?lems ranging from network connecti?vity to not understanding the meaning of a box on a checklist.

8. Ensure That Processes Are Used (Audit)

The SEPG ideally is only the “legislature,” defining the processes and ensuring that people know about them. Ideally another organization, generally a QA group, takes on the role of “police.” This will prevent fear of retaliation when people want to improve processes. However, the SEPG often has a role in persuading QA to take on this role in the first place, since in lower maturity organizations QA often audits only products, not processes. Acti?vi?ties include the following:

36) Develop a Process-Auditing Capabil?ity. Decide what kind of audits will be done for each process and what the auditors will verify. This process-audi?t?ing procedure ordi?narily is documen?ted as part of your QA process. The step here is to implement these audits by assigning names and dates and ensuring that the audits begin.

37) Decide What to Do With Audit Re?sults. To whom will they be reported? What are the standard elevation paths if the audits show problems? How are you going to col?lect and act upon the inevitable process improvement sug?gestions? “Compliance reports” can serve as recognition for projects that are using the processes reliably. “Non?compliance” reports can be sent to the sponsor so that he or she can require projects to defend their lack of use.

38) Train Auditors. Train auditors how to audit.

39) Develop Briefing on Auditing. Dev?elop a short briefing for practitioners on how to answer auditors’ questions. Interviewees should learn to answer specifics of this pro?cess use, not the whole history of the product, and should not feel impelled to say yes. Instruct them to say no if it is true, along with the short answer of why not. Deliver this training at the begin?ning of each audit, at least initially.

40) Plan Audits, and Publicize Plan. Determine which processes are going to be audited and when, both per pro?ject and organizationally. There should be both scheduled audits and “surprise” or ad hoc audits to be sure that the processes are being followed routinely, not only in advance of scheduled audits. Be sure auditing requirements meet any model require?ments (such as “verification” appendix to [CMMI 2001] ).

41) Do Audits. Audit, collect information, process the data per your plan, and report per the plan.

42) Improve Auditing Procedure. Im?prove the auditing procedure in accor?dance with feedback as needed.

9. Learn Lessons

Learning lessons is surprisingly difficult. Many people think they know how to run a project and are reluctant to take the time to hear what others did. Others are reluc?tant to “air dirty laundry,” despite the fact that we learn best from our own successes and others’ mistakes. Communication among tightly scheduled projects often must be forced. Finally, while recording lessons is critical, ensuring that people can and do access the lessons in a timely man?ner is also important. In order to ensure access and use, you may find that you need to add a step in between collecting and using lessons that organizes the recor?ded lessons and pushes them to the people who need to hear them. Activities include the following:

43) Lessons Learning Method. Deter?mine how you will learn lessons and share them [Popick and Smith 1997]. A periodic or phase-based lessons-learned process is superior to one at the end of projects, because many people have left the project by the end and those who remain may not remem?ber the earlier phases.

44) Learn Lessons. Perform your lessons-learned process and improve it if feed?back warrants.

45) Status Lessons Learned. Provide status on how well lessons are recor?ded, transmitted and used.

10. Improve Processes

This is the ongoing step of maintaining process descriptions to represent reality and to improve the description as improve?ments are noted in the performed process. Activities include the following:

46) Name Process Owners. Define the role of “process owner,” estimate resources, and sign people up to be process owners for all processes. The SEPG can “own” the pro?cesses, but another option is to have program personnel or functional areas own the process. It is good to get the practi?tioners involved in documenting and maintain?ing the processes, but they can get overwhelmed by program demands and let process work slip because it is not urgent.

47) Determine Process Review Proce?dure. Decide who will review and who will approve proposed changes. Deter?mine who is going to modify the pro?cess descrip?tions to incorporate the changes.

48) Charter Process Review Board. Determine the charter and the meeting plan for the review board that approves process changes. How much of this board should be project representatives as opposed to the process group?

49) Define Change Request Procedure. Determine how users will request pro?cess changes when they detect a pro?blem. Create a process change request form and a procedure for accepting, sorting, reviewing, and responding to them. Be sure you will provide feed?back to the originator about what you did with each suggestion.

50) Establish Process Upgrade Proce?dure. Establish a procedure for chang?ing the process descriptions and rolling out the changes, including required training. Will you upgrade the process descriptions all at once, periodically (say, annually), or perhaps every time a change is approved? If you upgrade them one at a time, what happens to interfacing processes? If you upgrade them all together, will you have suffi?cient proof that the change will work?

51) Solicit Improvement Ideas. Solicit process improvement suggestions from across the process improvement organi?zation.

52) Hold Review Board Meetings. Sched?ule meetings. In each one, review proposed process changes and determine whether each proposed change will be implemented. Analyze the impact of each change not only on project execution but also on training of this process (e.g., will anyone need retraining and how will the training change?). Plan the process change and how it will be rolled out.

53) Update Processes. Update the process descriptions and get approval.

54) Pilot Changes. Pilot process changes on a small scale if they are big or risky enough to have major negative impact on the organization should they fail.

55) Roll Out Changes. Update training and roll out per the rollout process. Measure the effect of these changes on the projects using the measurement plan established above in Step 4. Analyze and act on those measure?ments.

11. Appraise the Organization

Periodic appraisals allow an organization to measure the success of a process improve?ment effort, using a standard maturity model. Some use such results to compare their own abilities to other com?panies in the industry or to other organi?zations within the same company. Many companies that achieve high maturity levels focus on that achievement in mar?ket?ing the company’s abilities. Finally, some customers require achievement of matur?ity levels for bidding purposes. In general, an appraisal not only gives a level but also information that can be used to re-energize and possibly retarget the process improve?ment effort.

Organizations performing process improvement to a model often focus too much on obtaining the level number, some?times to the detriment of actually funding improvement rather than apprai?sals. Nevertheless, the awareness that an appraisal is coming often serves as the impetus to complete process improvement actions. Use an external appraiser if your organization wants additional credibility in its claims of process improvement success. If you are choosing to perform appraisals, then they are planned separately from the audits above. Activities include the following:

56) Schedule Mini-Appraisals for the Near Term. Determine when you will want mini-appraisals to verify that the processes are being implemented. These could be peri?odic but may occur after training or per project.

57) Plan and Prepare Each Mini-Apprai?sal. For each mini-appraisal, plan and prepare. If necessary, re-verify that the processes as currently documented meet the needs of the model and of the organization.

58) Perform Each Mini-Appraisal. Re?spond to mini-appraisal findings.

59) Plan Full Appraisal. This includes engaging an official appraiser, if desired, and may include using that appraiser as part of a dry run appraisal. Appraisers may also par?tici?pate in or even drive mini-appraisals.

Perform Full Appraisal. Ensure wide?spread upper and middle manage?ment atten?dance. Be sure the sponsor knows what to say to the appraisal audience?some sponsors threaten punishments if level goals are not met, while others discount the importance of the process improvement effort by “cheerleading” the worth of “the way we do business here.” Either type of speech can undercut the process improve?ment effort.

60) Set New Goals. Celebrate accomplish?ments, set new goals, and continue.

Conclusions

While developing usable processes for an organization, it seems that implementation will be easy by comparison. However, the many steps explained above must be taken to ensure that there are no surprises.

Four main groups contribute to the success of the process improvement initi?ative: senior management, the SEPG, the organization’s programs and projects, and the QA group. These groups must com?bine their roles and talents to the joint goal of improving the organization. These groups are responsible for the following activities:

· Senior management sets the tone and ensures that other managers want to make the process improvement happen.

· The SEPG, whose leadership must be senior enough to provide credibility, drives the process improvement pro?gram to meet its goals.

· The programs and projects must make time to recommend improvements, review processes, and then pilot and implement the processes. All capabil?ity models recognize that if the projects are using processes, the organi?zation is; if they are not, the organization is not.

· The QA group provides an indepen?dent check that processes are being used.

This paper lists the steps that these groups need to perform, once new processes are defined. The steps and guidelines should be useful for a process group that needs to estimate and plan an implementation effort.

References

Capability Maturity Model Integrated (CMMI) Assessment Method Inte?grated Team, Standard CMMISM Appraisal Method for Process Im?provement (SCAMPISM), Version 1.1: Method Definition Document, CMI/ SEI-2001-HB-001, Carnegie Mellon Univer?sity, 2001.

Sheard, Sarah A. “What Is Senior Man?age?ment Commitment?” Proceedings of the 11th International Symposium of the International Council on Systems Engineering, Mel?bourne, Australia, 2001.

Practical Software Measurement Guide?book, Version 4.0b update, November 2000. Avail?able at www.psmsc.com .

Popick, Paul R. and Craig L. Smith., “A Team Method to Capture Concurrent Engineer?ing Lessons Learned,” Cross?Talk, January 1997.

Biography

Sarah A. Sheard received the 2002 INCOSE Founder’s Award for her work in INCOSE, inclu?ding publishing over 20 symposium papers, chairing the Measure?ment technical com?mittee and the Com?mu??ni?cations committee, and serving as program chair and Direc?tor of the Wash?ington Metro?politan Area chapter. Ms. Sheard has worked in systems engineering and process improve??ment for over 20 years and is currently a Chief Tech?nolo?gist leading the systems engineering effort at the Software Productivity Consortium.

? Capability Maturity Model ® and CMMI® are registered in the U.S. Patent and Trademark Office. SCAMPISM is a service mark of Carnegie Mellon University.

? Generally this is important for government agencies only, as contractors already are accustomed to disciplined use of time cards.

 

© Software Productivity Consortium NFP, Inc. Page 1 of 3

pur-new-sol

Purchase A New Answer

Custom new solution created by our subject matter experts

GET A QUOTE