If you qualify as a non-accelerated filer (i.e., your company’s public float is under $75 million), you’ll have to start complying with Section 404(b) of SOX, which requires company management and independent auditors to sign off on, or attest to, the effectiveness of your risk control framework or accounting policies and procedures for internal control.  Are your processes protecting you from the risk of material misstatements (RMM)?

Sarbanes Oxley Compliance Costs Too High?

When it was first enacted, the Sarbanes-Oxley Act (SOX) did not apply to non-accelerated filers because it was believed SOX compliance costs would be too high.  Several delays and extensions have been given to non-accelerated filers because the Office of Economic Analysis, which advises the SEC, needed to complete a study on SOX compliance costs. The study was completed in September, 2009, and was quickly followed by the announcement (on October 2) of the June 15th compliance deadline.

It didn’t surprise anyone when the OEA study showed that SOX compliance costs increase with company size; the study also confirmed that annual compliance costs decrease over time and that, overall, compliance costs have decreased since 2007.  In other words, while larger companies achieving SOX compliance had higher costs overall, there are fixed SOX compliance costs that impact all organizations, regardless of size, and companies have gotten smarter on how to implement Sarbanes-Oxley.

How Do You Control Sarbanes-Oxley Compliance Costs?

There are three major factors that drive up the cost of complying with SOX: cost of scale; cost of review; and cost of improvement.  The more control you have over all three of these, the lower your costs to implement Sarbanes-Oxley compliance will be.

Sarbanes-Oxley Cost of Scale

Why do larger companies incur higher overall compliance costs?  Because of the sheer size — scale – of their operations!  More operating locations, more employees, and more processes means more time and people needed to review accounting policies, procedures, and internal controls.  There is no easy answer to the question of scale: larger size translates into more risk management, internal controls, and accounting processes.

You can reduce the scope of SOX compliance by addressing the greatest risks first (note that PCAOB Auditing Standard #5 was developed for this purpose).  Don’t try to address all risks at once — this is what drives up compliance costs.  But, which risks do you address first?  Determine a threshold, or cutoff, for risk materiality, then decide which risks are most material to your company.

Remember — this is an ongoing process of improving your SOX compliance, not a one-time SOX compliance event.  Next year, you can (and probably should) lower the threshold and address your “second-tier” risks, and continue to annually adjust your threshold until you are comfortable.  Management decides on the internal controls needed to cover the identified risks.

Also, if you decide wrong and set your risk threshold too low or too high, you’ve identified a material weakness in your risk control framework.  You think you’ve exposed a flaw in your system, but consider that your system is also about continual improvement.  The only flaw is failing to improve: work on improving your internal controls - adjust your risk threshold - and you can demonstrate that you have a SOX-compliant system.

Sarbanes-Oxley Cost of Review

The cost of review represents the Check and Act phases of the Plan-Do-Check-Act (PDCA) process approach.  All companies needing to comply with SOX have to have some form of review process that tests accounting’s internal controls and gives management the confidence to attest to the validity of the company’s financial statements.

Internal audits, management reviews, management and auditor attestation, and board oversight are fixed costs of Sarbanes-Oxley compliance.  Every company has to operationally demonstrate to top management that internal controls are in place and are working.  Larger companies have to spend more, of course, but every company must spend a minimum amount for basic compliance.

As with the cost of scale, you can reduce the scope of SOX compliance by addressing the largest risks first in your audit plan.  You don’t have to audit every accounting process every year.  Start with the accounting processes that have the greatest impact — those that pose the greatest risk of material misstatement if they don’t work.  Review past audit opinions, your compliance plan, and your definition of materiality and adjust your audit plan to deal with the greatest risks.

Management decides on the internal controls and testing needed to ensure that the identified risks are controlled.  If you find that your audit plan hasn’t addressed the right risks, you adjust the plan.  Again, lessons learned — and implemented — show that your system is driving improvement and is, therefore, Sarbanes-Oxley-compliant.

Sarbanes-Oxley Cost of Improvement

The cost of improvement comes under the “Plan” and “Do” phases of the PDCA process.  Sarbanes-Oxley compliance starts with a compliance plan, one that identifies the risks you need to control.  Your compliance plan is the foundation of your risk control framework.  With a sound compliance plan in place, management can make better decisions regarding internal controls, such as implementing accounting policies and procedures that reduce or eliminate the risk of material financial misstatement.

Developing accounting policies and procedures is the “Do” in “Plan-Do-Check-Act”.  Your risk control framework identifies individual risks (e.g., the chance a receivable is not collected on time). Your accounting policies (e.g., collect accounts receivable within 30 days) and procedures (daily A/R aging reports, phone calls, collection letters, etc.) are forms of internal control that demonstrate your compliance with Section 404 of SOX.

Are your accounting policies and procedures for compliance, or control?  Well, control comes before compliance, but many companies have confused the two and wasted a lot of time and money.  You can reduce the scope of SOX compliance by controlling your greatest risks first with your accounting policies and procedures.

You don’t have to write a policy or procedure for every accounting process at once.  Once again, start with the accounting processes that, if they don’t work, pose the greatest risk of material financial misstatement.  Review audit opinions, your compliance plan, and your definition of materiality, then develop and implement the accounting policies and procedures that address your greatest risks first.

Management makes the final determination of which accounting policies and procedures are needed.  If you develop cash policies and procedures that do not (adequately) control the identified risks, you have a material weakness.  Improve your accounting procedures for internal control and you demonstrate Sarbanes-Oxley compliance.

Bizmanualz Accounting Policies and Procedures Reduce Sarbanes-Oxley Compliance Costs?

Sample accounting policies and procedures serve as a model, or framework, for your own accounting policies and procedures.  The CFO Accounting Policies and Procedures Manuals set contains over 200 procedures that address the ten accounting cycles.

SEC Chief Mary Schapiro recently stated that “there will be no further Commission extensions.  It is important for all public companies - and their auditors - to act with deliberate speed to move toward full Section 404 compliance.”  Although legislation has recently been introduced to permanently exempt non-accelerated filers from Sarbanes-Oxley Section 404(b) compliance, there’s no guarantee that Congress will act or that the public won’t demand better information and you won’t need to comply with 404.  Besides, having an effective system of internal controls makes good business sense.

Using prewritten procedures will save you hundreds — possibly thousands — of hours in researching, writing, and implementing accounting policies, procedures, and internal control for Section 404 compliance.  Save even more time implementing additional internal controls for sales and marketing, security, disaster recovery, and ISO 9001 compliance using the CEO Company Policies and Procedures Manuals.  Download free samples of our procedures and judge for yourself.

Checking the procedure is a form of procedure verification.  You run a test before implementing the procedure to verify that the procedure works and meets all the design requirements.  But how do you know if the procedure will work outside of the design space ?  Will it work in the real world, with real users?  At this point, we are beyond procedure verification — we need to validate the procedure to ensure the process and procedure are working.

You are not done with your procedure until it has been validated.  After all, you wrote the procedure to close some gap in compliance, quality, or performance — how do you know your procedure is actually closing the gap?  Procedure validation consists of performing procedure training, process auditing, and completing a process procedure management review that will allow us to confirm that the gap is closed, the process is working, and the procedure works.

Process Procedures Implementaton and Training

Procedure validation starts with process implementation and procedures training.  Procedure training will be your first feedback from the actual users.  Gather the procedure users together and brief everyone on the main procedure tasks, changes, and process objectives.  Use your process maps to visually explain the process.  Highlight individual responsibilities for key performance metrics.  Ask questions and obtain feedback.  Remember: your procedure goal is “a working process”.

If you have a lot of users from multiple work cells or geographic locations, you need to prototype the new procedure — test it in one area before implementing it across the whole business.  Your procedure validation should occur before a widespread implementation.  In a small organization with limited scope, this is often not practical.  In that case, process auditing is critical to ensure that the procedure works.

Process Procedures Audit

Once employees are trained, how do you know if the procedure works or is being used correctly?  To find out, you need to audit the procedure at some point after procedure training. Process auditing is an internal audit of the process and procedure.  At some interval after training, you need to follow-up on your new procedure and see how it’s being used.  Is the procedure followed?  Is the procedure effective?  Is the process working?  Is the procedure working?  Is the procedure integrated into the process?  Simple questions, but they all must be asked.

If the process or procedure is critical to quality, compliance, or performance, you should perform a process procedure audit sooner and more frequently (perhaps 7, 30, and 90 days apart).  You are still in procedure validation and you need feedback to determine if your procedure is working.  Once validation is complete, you may be able to back off the process audit (e.g., cut back from monthly to annually): it all depends on how well the process is working and how critical it is to your firm’s success.

Process Procedures Review and Change Management

Once audited, how will you know if the procedure is performing as expected?  To find out you will need to analyze the audit data and process performance and hold a process procedures management review.  If you started your process procedure journey with a project charter, you have your original quality, compliance, and performance objectives.

Compare your audit data with the project charter to determine if your procedures work, if the process is working as expected, if you’re ready to close out procedure validation, or you need to make changes to improve your process procedures effectiveness.  Change Management can be tricky here.  Process optimization comes later, after you close out the original design, the process is going for a while, and you’re ready to improve once again.  For now, focus on important procedure changes to achieve the original objectives, in order to prevent scope creep.

Conclusion

We started the process procedure journey with a procedure implementation plan.  Your process procedures project continued with a process map, documenting your process procedure design.  If a procedure was required, you had to write a procedure.

The process procedures journey ended with procedure validation, where you ensured the process was working and the written procedure worked.  Once validation is complete, you’re ready to start your next process procedures journey.

Required Policies Procedures

Only company policies and procedures required by standards, regulations or company strategy must be developed.  ISO 9001 requires only six procedures, so why do many companies feel they need to write 40 or more procedures to achieve control?  Occasional users need procedures as a reminder of procedure steps that they do not perform very often.  Frequent or regular users do not need, and often times do not use, the procedure.  So how are those other 34-plus procedures used?  Most procedures are used to train infrequent users.  For training purposes you may only need a process map.  Are you using your procedures to make up for a weak training program?

Your Policies Procedures Template Design

When you do write procedures you will need to standardize on a procedure template design.  Start your policies and procedures template design by thinking through your document and record control procedures.  Your procedure template design should make room for a header block to ensure your procedure communicates your purpose and scope.

Add a Title, Policy, Purpose, Scope, Responsibility, and Definitions section to help people understand your procedure. Clear department responsibilities identify who does what and helps to declare which positions are mentioned in your procedure with a synopsis of what is expected for each position. Key term definitions reduce confusion; industry jargon should be explained in the definitions section of your procedure to help new procedure users.

Writing Policies Procedures

Before you start writing procedures from scratch, look around for examples, or templates, that you can copy.  Pre-written procedures will speed up your development, reduce your research time, and turn writing procedures into editing procedures.  I’ve found it’s a lot easier to edit a procedure than to write one from scratch, depending on the procedure.  Many procedures are really common using business best practices, so why reinvent the wheel?

If you have to write a procedure from scratch, start writing procedures using active voice construction to reduce task confusion. Subject, verb, object provides clear active voice construction for your procedure.  For example, “Accounts Receivable invoices customers” is clearer and contains fewer words than “customers are invoiced by Accounts Receivable.”  The extra “are” and “by” make the sentence longer, put the subject last, and force the reader to stop and reread the action.  Be direct and to the point — use the active voice.

Add references to related documents to improve your procedures’ usability.  Clearly note when your procedure refers to other procedures or forms.  There’s nothing worse than following a procedure and coming to a passage that refers to a company form and…that’s it. You don’t know what the form looks like, where you might find it, or what version of the form you need.  Putting an example of the form, with an explanation, in the procedure will save you and your users time during procedure training and implementation.

List applicable laws or regulations: clearly communicate your company’s need for compliance.  If you’re implementing a records retention procedure, references to IRS or equal employment opportunity (EEO) passages, for example, provide a brief synopsis and help you implement your procedures.

How to Write Policies and Procedures

Policies Procedures Overhead

Large organizations have a large number of procedures.  They have a lot of staff, business operations, and economy of scale to make their procedures work.  Smaller businesses should remember — the more business procedures you write, the more business procedures you have to edit, implement, train, audit, and review.  More procedures may also produce more audit findings in addition to more updates, more documents to control, and more administration overhead.

Many companies fail to plan for this administration and procedure overhead, so it should come as no surprise that their procedures don’t work as well as expected.  Every procedure becomes outdated, eventually.  Also, due to infrequent maintenance and use, some procedures are overlooked when it’s time to update them.  This can result in repeated procedure audit findings or, worse, repeated waste, fraud, and abuse which the procedures were intended to reduce.

The lean thinking solution is (a) to write only procedures that you absolutely have to write to conform to requirements and (b) to improve your training program to build competent and skilled employees instead of writing procedures you don’t have the time or budget to maintain.

Next week, we’ll cover policies and procedures implementation and training.  It’s much easier to comply with standards and train employees when you’re working with written procedures.  If you’re interested in learning more about your procedures, call or e-mail us for a procedure review of your written procedures.  We’re happy to provide feedback on what you’re using and tell you how you can improve your processes.

How can you use the individual steps of your process procedures journey to focus your business on:

• Adapting your core business processes to process change?
• Building repeatable business processes?
• Adhering to process standards or regulations?
• Managing your business processes more effectively?

Each step of your process procedures project results in an important milestone being reached.  Your entire process procedures project will move along better and quicker, with better results, if you achieve each milestone.

Figure 1 depicts the business process procedures journey work flow.  The journey starts with project management.  The extent of a business process change can be large or small — they may or may not require written procedures — but even small process changes require basic project management to avoid having the law of unintended consequences catch up with them.

1. Process Procedures Project Management

To get the buy-in of your employees, start your process procedures project with a project charter that focuses your team on clear project goals and objectives.  For example, if you’re working on an accounts receivable process, be sure receivables clerks consistently follow the process.

Your process procedures project plan should allow time for the six steps in your process procedures journey: allow about 12% for project planning, 13% for process design, 25% for procedure writing, and 50% for process procedure implementation, training, process auditing, and a management review at the end of the project (Figure 2).

Figure 2 - Process Procedures Project Time

Process procedures project management key milestone: completion of your project charter and project plan.

2. Process Mapping and Process Design

Your procedures process map should include the sequence of process steps with clearly defined inputs, documents, and records.  Make a special note of the process flow metrics, responsibilities, and goals.  For example, an accounts receivable process should note the invoices per hour processed, who is responsible for cash, write-off, or discount approvals, and how close the process is to the goal of collecting within thirty days.  This information will help with later procedure writing, process training, and process auditing.

For many business processes, a process map may be the only documentation needed.  Not all processes require procedures, work instructions, or anything more than a process map.  In fact, a form may be all you need.  It is really a matter of scale: the more employees you have involved in a given function — the more complex it is — the more formal process documentation you’ll need.

Process procedures process mapping and design key milestone: complete “current state” process map with process data.

Next week, we’ll cover writing policies and procedures.  Procedure writing is a result of formal, required compliance and training.  It is often much easier to comply with standards - and train employees - when you work with a written procedure.

If you’re interested in learning more about your procedures, e-mail us at info@bizmanualz.com or call us at 314-863-5079 for a procedure review.  We’re happy to provide feedback on what you’re currently using and show you how we can help you improve your processes.

Your business process procedures journey is driven by your business needs: need to survive, need for effective process change management, need for process consistency, need for process compliance, and need for process control.  Your entire business model is in jeopardy if you fail to adapt to change, build repeatable business processes, adhere to process standards and guidelines, observe regulations, and manage your business processes and process change effectively.

You can achieve effective business process change management, process consistency, process compliance, and process control by focusing on your business process procedures journey (Figure 1), a six-step process comprised of the business process management topics we talk about on the Bizmanualz.com website.

Business Process Procedures Flowchart

Figure 1 - Business Process Procedures Journey Flowchart

Notice how we talk about processes and procedures together.  Your business model is a system of processes.  Business processes need to be identified, communicated, and reviewed for there to be an effective change management process, with effective opportunities for business growth in place.

In Figure 1, the procedure writing steps are colored in red, to signify their optional status.  Not all processes require procedure writing; there’s a lot of overhead tied to every business procedure you write so that the more business procedures you write, the more procedures you have to edit, implement, train people on, audit, and review.  Only company procedures required by standards, regulations, or company strategy must be developed.

Michael Gerber’s book, the E-Myth, explains how important it is for entrepreneurs to think about working “on” their business instead of “in” their business.  Working too closely inside of your business processes is sometimes referred to as “business myopia” — being too close to your processes can keep you from advancing on the business process procedures journey.

Once you start working on your business — not in it — you can identify key business processes, practice communicating critical business process metrics and information, and review those business process metrics against the changing marketplace.  Now you are in control of your business process improvement.

This month we’ll be showing you how to advance — how to implement — each of the six steps of the Business Process Procedures Journey:

1. Process Procedures Project Management
2. Process Mapping and Process Design
3. Required Procedures (optional steps)
   • Policies and Procedures Template Design
   • Policies and Procedures Writing
4. Process Procedures Implementation and Training
5. Process Procedures Audit
6. Process Procedures Review and Change Management

In our next article, we’ll explain how you can use the individual steps to focus your organization on adapting your core business processes to business process change, build repeatable business processes, adhere to process standards or regulations, and manage your business processes more effectively.

The first phase in any project management process is Project Initiation.  The second phase is Project Planning.  Together the first two phases represent the seven “Ps” of planning:

Proper Prior Planning Prevents a Pretty Poor Program.

But you are not preparing planning for planning’s sake, you need the deliverables.  The next phase - Project Execution - is the area most people spend most of their time.

Project Management Phase III: Project Execution

Project Execution is the third phase in any project management process.  It consists of developing, executing, and creating or building the project deliverables.  The hard core planning elements prepared you for what you have to create; now you have to create it.  Your output at this phase could be design documents, prototypes, examples, samples, or actual product, which should be accompanied by verification test results that substantiate that the deliverables meet the requirements.

Typically project execution is a construction phase.  In the case of a process improvement project, Project Execution consists of constructing the solution or understanding the root cause and implementing the appropriate corrective action.  After Project Execution, you move to Project Monitoring and Control.

Project Management Phase IV: Project Monitoring and Control

Project Monitoring and Control is the fourth phase in any project management process and consists of…well, monitoring and control.  It is the last step of the six sigma DMAIC process and is critical for process improvement — ensuring that the problem is really solved.

Key variables are monitored to determine if they remain within tolerable ranges, so that your process improvements are maintained.  In a custom home building project, monitoring might occur during the warranty period.  The home owner would monitor their new home and report issues that come up.  Once the monitoring period is complete, you are ready for the Project Review and Close phase.

Project Management Phase V: Project Review and Close

Project Review and Close is the final phase in any project management process and consists of closing out the project.  ”I’m done with the project”, you’re thinking.  ”What else is there to do?”  There are three important elements of closing out a well-managed project: final project housekeeping, project review, and the project close-out report.

Project housekeeping consists of the project tasks that wind down your project:

• Complete final acceptance sign-offs;
• Complete the project review;
• Archive all documents and records;
• Recognize exceptional project achievements and discuss a project celebration event;
• Return project resources - people, facilities, and equipment;
• Write the final status report and create the project close-out report; and
• Communicate project successes and project management recommendations.

Project review is really what this phase is all about.  You need to collect feedback from the project team (individually and as a group), management, the customer, and your suppliers.  Project feedback is about knowledge management — capturing “lessons learned” for the sake of future projects.  Make sure you identify project successes and problems for future project managers — one of them could be you!

People performing different functions on the project bring their own knowledge and experiences and they each have a unique, different view of the project’s successes, failures, and possible solutions.  They see and hear things others don’t, and vice versa.  Ensure that each project stakeholder group is represented — and participates — in your project review.  Remember, it is the users’ view of the project and its deliverables, along with the view of the major stakeholders, that will live on long after your project is complete.

Important project review questions to ask include:

• Do we have a list of went wrong and why?
• What do the customer satisfaction data say about our project?
• Have all handoffs and project transitions to the customers been completed?
• Are there any outstanding issues, activities, or risks?
• Is technical support in place?
• Was the project organization, including staffing and skills, appropriate?
• Were the schedules effective?
• Did the processes for change control, quality, and configuration management work well?
• How effective was the project communication plan?
• Were our success factors met?
• How was our time/budget variance and performance?
• What are the recommendations for future project managers?

The project manager is responsible for preparing your final deliverable for the project, the Project Close-Out Report.  In the project review, the project manager obtained input from the project team and other major stakeholders.  Now it is time for the project manager to organize the project review data into concise, cogent project information, harvest the project wisdom, and communicate the project results.

The project close-out report represents your stakeholder’s final thoughts on the project.  It starts with summary descriptions from your project charter, explanation of project performance, operations management issues, documentation archives, and concludes with your project recommendations for future projects.    You may include a list of project close-out items that demonstrates the project housekeeping activities are complete.

Your project sponsor approves your report and you are done, right?  Almost.  You must distribute the report, too.

Your project close-out report should include:

• Project title, date, and author;
• Project description, goals, and benefits (from the project charter);
• Performance baseline (target versus actual);
• Operations management handoffs and issues;
• Project documentation archives;
• Lessons learned and recommendations;
• Project close-out checklist; and
• Approvals.

Documenting project review data is not enough — you must share the project successes and lessons learned with others in your organization.  Consider adding this information to your project management procedure.  Use your project close-out report — establish or continue your knowledge management process — so the lessons learned are there for the benefit of future projects.

At this point, your project management event is complete but your project management process is ready for the next project.

Project planning is the second phase of any project management process and consists of developing the core planning elements.  The output of this phase is a set of project management documents, or plans.  The most important one is the project plan itself.  (Figure 1 shows the table of contents for a project plan.)

Figure 1 Bizmanualz Project Plan Template

The project plan starts with (1) the project overview, where you summarize and introduce the project.  This is your “management abstract”.  Management may not read much else, so you have to make an impact here. Explain the ROI, user experience changes, and the benefits of the project.  Don’t just list the project features — the deliverables, schedules, milestones, and costs.  Explain the benefits to the user, or customer.

Next, your (2) project organization describes the reporting structure, or organization chart, along with the roles and responsibilities for the various project team members, including customers, suppliers, and other stakeholders involved in your project.

Everyone has a role.  Customers approve requirements, may participate in testing, and are definitely part of acceptance.  Suppliers are involved in your procurement.  Note the interfaces to all stakeholders.

In many projects, various resources may be involved only part of the time: clarify individual roles and responsibilities and their level of involvement.  A 10% resource may become a critical bottleneck because 90% of their time is being used on other projects.  Don’t just make a superficial list of resources — note in detail all resource issues and your project structure, to minimize project risks.

If management wants to see the details to items mentioned in the project overview — time, money, and risk control — the (3) managerial process plan is where management will find them.  How will the customer’s money be controlled?  If risk is a big issue, a separate Risk Management plan may be referenced.  Are there any issues — hurdles, bottlenecks, dependencies, etc. — that may affect the project’s Closing?  If so, think through the Project Closeout plan to note key handoffs, maintenance, or future training issues.

Technical details are covered under the (4) Technical Process plan.  Special test equipment, development hardware, expertise, or facilities are explained, to provide cost justification in the budget.  Information from the feasibility study may be referenced or included to explain the design approach, methods, or other design inputs.

It is important to explain what acceptance will mean, so everyone will know when you’re done.  The Acceptance plan describes how acceptance will occur, those responsible for acceptance and the criteria for acceptance testing.  If the solution will be rolled out to a big or a complex group, a Deployment plan may be in order.

Other planning details are included in (5) supporting process plans.  Here you can include additional project planning documents, such as:

• Communications Plan
• Quality Plan
• Procurement Plan
• User Training Plan
• Test Plan

In a large project, these plans could be separate documents (and probably should be, with ample details).  In a small project, you could simply incorporate them into the project plan document.  Either way, it is important that you make it clear how you intend to face the planning issue.  Leaving out an important project planning element could be a cause of project scope creep, leading your project into time or cost overruns and possibly failure.

Let’s say you’re working on a set-up reduction process improvement project.  Your plan focuses on one work cell at one plant that has three shifts.  Management suggests you take the improvements on the road to the other eight plants.  Stop and think…is this scope creep?  It is if your original plan didn’t address training a large number of workers across the country.  (It didn’t, did it?)

For the “other eight plants”, you need to see results from the first one.  Only when you’re satisfied with those results do you develop a new project charter and a new project plan with a new budget for the other eight.  Your new project plan needs a communications plan and a user training plan of its own.  Additional training resources will be needed.  In other words, despite the similarities, this is a different project.

The Project Plan is your most important project management document.  The Project Plan and its supporting plans are your primary management control mechanisms.  Your project Plan contains the information you use to control the project’s resources and prevent scope creep.  Use your Project Plan to explain to management what they are asking for — stay in control of your project.

Phase I - Project Initiation

The primary purpose of Project Initiation is to discover the project’s scope — where are its boundaries?  As you see in Figure 1, you need to determine and document the User Requirements & Project Assumptions, produce a Business Case Justification & Feasibility Study, and put together a Project Charter and Project Team.

User Requirements & Project Assumptions

You need to collect data, objective evidence, and examples of the business problem at hand in order to begin framing the project.  Start by interviewing users to answer some basic questions:

• Who or what groups are impacted today?
• What pains do they experience?
• What will the improvement look or feel like?
• How will the environment or daily work practices change?
• What are the desired project benefits and costs?
• What cannot be done and why?

Talk to management about their project assumptions — time frame, budget, resource availability, standards, regulations, and other data — because they impact the problem. Note: You are not solving the problem yet, but quantifying it.  It is important to collect facts at this stage.

In this stage, “facts” include assumptions and perceptions, so get everything on paper and/or recordings.  Use an audio or video recorder to collect quotes.  You will use all of these facts to build your business case justification.

Business Case Justification & Feasibility Study

You start your business case research with a feasibility study.  Now that you know what users want, you need to find solutions, technologies, or methods that will help resolve their issues.  Collect qualitative data from your process analysis, industry benchmarks, and through industry research.

Your feasibility study will:

• Define the business issue, problem, or opportunity
• Research industry benchmarks, technologies and methods
• Determine industry solutions, alternatives and trade-offs
• Explain selected solutions, their benefits and risks
• Provide solution recommendation

One of the most important details at this stage is the Return on Investment (ROI).  You’re asking management to make an investment — management expects to get some type of return on the investment.  Usually you’re asked for the financial ROI but even if the return is intangible, you need to justify the expenditure.

Start by determining your objectives, measure,s or cost variables and establish a baseline figure for comparison.  Project baseline and expected results (as per objectives) should be for a reasonable interval (e.g., 12 months) after project completion.  Be sure to explain how or when the sponsor/champion will experience the effect of the cost savings or other justification.

Management may also want to know the risk exposure and how this investment compares with alternative capital uses, using Internal Rate of Return (IRR), Economic Value Added (EVA), or Net Present Value (NPV) calculation. Conclude with the total cost of ownership, or TCO, including intangible benefits that will be realized, too.

You are now ready to build your business case justification using the data from your user requirements, project assumptions, and feasibility study. Your business case is designed to convert all the data into information that convinces management - or the customer - that your project will deliver positive results. It should answer who or what groups are impacted, what the benefits and risks are for the selected solution, and what it will cost in terms of time and money.

Project Charter

Projects start with an idea, yet we don’t know what we don’t know. Projects require some learning and solutions will evolve.  So, how do you focus a project team on your solution? You start with a project charter, used by the project manager to document and communicate a common understanding of the project with all stakeholders — management, customers, and the project team. The project charter focuses the project team on the main elements of the project in order to control the dreaded scope creep that often seems to invade projects.

Scope creep: small changes that, individually, may appear acceptable but collectively, add up to significant project expansion.  Effectively manage the scope and you effectively manage resources and, ultimately, the project.

Think of the project charter as a contract formed with the project stakeholders.  I like to keep the project charter to a single page that can be posted on the wall as a constant reminder of what the project is all about (Figure 1).

Figure 1 - Project Charter

The project charter defines the project’s main elements:

• Box 1 - Problem Statement, or definition, and Scope - what areas are included and excluded from the project;
• Box 2 - Quantifiable (SMART) Project Goals, and estimated Benefits and their relationship to business objectives;
• Box 3 - Milestones or Tollgates, and Next Steps; and
• Box 4 - Approvals

Some individuals may include project constraints, budget, risks, resources, assumptions, stakeholders, revision history, funding authority, oversight, project structure, roles & responsibilities, and even a glossary in their charters. Personally, I feel that once you add all of this you have a project plan, not a project charter. You definitely can’t keep something like this to one page if you add all of this.  A charter is an overview: I say, save the details for the project plan (more on that subject next week).

The project charter is the first step in a disciplined project management process.  A project charter assists you in project governance, demonstrates you are following project management best practices, and it’s a great tool to get buy-in from everyone involved.

What Are Some Project Management Tools And Methods?

• Implement a project using the five project management phases;
• Initiate projects with User Requirements & Project Assumptions, a Business Case Justification & Feasibility Study, and a Project Charter & Team Selection.
• Use the project charter (Figure 1) to focus the project team on the key project elements.
• Close out the Project Initiation Phase with a phase review.

Next week, we’ll talk about the second phase of the project management process: Project Planning.

A Project is a temporary collection of related tasks to achieve a desired and usually unique result.

What do you think? Do you find yourself managing a collection of related tasks to achieve a desired result?  If so, you qualify as a project manager.  Businesses today are evolving, downsizing, and pushing more work down the organization chart.  You may be a project manager and not know it.  But what if you haven’t been trained as a Project Manager with the necessary skill and tool sets?

This month, we’re going to talk about the project management process and try to answer some questions that every project manager (or would-be project manager) should have the answer to:

• What is project management?
• What are the five phases of project management?
• What are some project management tools and methods?

What Is Project Management?

Projects are unique events and not processes, yet project management is definitely a process and not a unique event.

Project Management is a disciplined utilization of tools and methods for successfully describing, organizing, and controlling a project.

Project management is a structured process of disciplined actions that follows a common Plan-Do-Check-Act (PDCA) cycle found within the five phases of project management.

What Are the Five Phases of Project Management?

• 1. Project Initiation
• 2. Project Planning
• 3. Project Execution
• 4. Project Monitoring & Control
• 5. Project Review & Close

Figure 1 Project Management Document Map

All projects go through the same five project management phases that typically culminates in some type of project management phase review (see Figure 1, Document Map).  Each project management phase has a distinct purpose, importance, and set of outputs designed to ensure that the project manager is moving the project toward the desired result.

Following a disciplined project management process should help you to eliminate common project issues resulting from poor buy-in, projects consistently going wrong, failing to learn from past project mistakes, or difficulty in getting your projects approved.

Project management begins with the “Project Initiation” phase.  Next week, we’ll  describe this first phase — its purpose, inputs, and outputs — in some detail.  In the following weeks, we’ll explore the remaining phases of project management — planning, execution, monitoring & control, and close & review.

At the heart of your improvement plan should be a strategy.  Rendered maps can help you visually represent that strategy.  You need to paint an attractive picture — show a positive future, show the outcome that people will buy into.

We illustrated a strategy of faster turnaround for aircraft overhauls. It was simple. Workers could easily see how the changes being asked of them would result in good outcomes.

We helped an aircraft overhaul facility, or MRO, cut the time required for major service on aircraft overhauls.  Less time in the shop means operators get their planes back in service faster which, in turn, means they make money instead of spending it.  That helped the aircraft overhaul facility garner a competitive advantage.

We mapped process flows and activities throughout the company; for example, how materials were specified, requisitioned, and tracked.  With our process maps, the client saw how small changes would flow through the system and have a big impact.

Had you asked department managers at the time, they would have told you they were already aware of most of the improvement opportunities that we identified. Certainly, the inefficiencies had been there for years, managers would have said. And point solutions had been identified in some cases.

But the eventual impact of small changes was unclear or unknown, so it was hard for them to justify the time and resources needed to effect change.  So, improvement flagged.

Lighting a fire for change meant we had to change minds.  We illustrated an improvement story that showed certain small changes having a big impact.  Using rendered maps, we illustrated the strategy that was easy to buy into.  We also illustrated a number of systemic improvements that would help sustain the improvements.

Show the Positive Future and Give People a Reason to Change

For example, we selected and illustrated how highly skilled mechanics were spending time and many footsteps getting parts.  Everyone understood that if a wrench doesn’t turn, the plane doesn’t move, and turnaround suffers.

This rendered process map shows mechanics' walk and wait times in the current state. Inefficiency and waste are readily apparent.

In the future state, we instead showed parts being delivered to the mechanics:

In contrast to the current state, the future state is much simpler and, therefore, a marked improvement. As a communications device, it leads workers to ask what is required to achieve and sustain the improvement.

It sounds simple, right?  It was simple, and it tied in with the overall strategy of reducing turnaround.  It made it a great story.  Ultimately, it was the story that had been lacking in the past.

The story, told in rendered maps, helped us get the buy-in that was essential to support the many process changes required to sustain change.  How would the runner know what part to deliver to the mechanic?  When would the  part be delivered?  How would chain of custody be maintained?  Many questions arose that, before, simply froze out improvement, but by telling a story for positive change, the hard work of change became tenable.

By virtue of our illustrating specific improvements, people could see exactly how that lofty strategy translated into their daily work lives.  Our story consisted of sufficient current-state and future-state improvement “concrete steps” and examples to show that improvement was, in fact, possible and exactly how the “positive future” of reduced turnaround time could be achieved.

Telling the Improvement Story Is Part of Your Job

Had we stopped at producing the descriptive maps and left it up to the department heads to structure an improvement program, they surely would have made some incremental improvements in their system.  However, their efforts would have lacked urgency and sustainability.  Change would not have happened fast enough to outpace the industry.  Hungry competitors would not have been overtaken, and no sustainable competitive advantage would have been achieved.

But it was achieved.  As we learned, it’s part of our job as leaders to tell the improvement story. Rendered maps are a tool for telling stories of positive change. Fact-based, tangible, visual stories can illustrate a positive future, and should be in your process mapping toolkit. So, tell the story. Complete the improvement journey. Use a map.