Topic & Key Points

1

Problem:  You know that most large computer projects are late and over budget.  

When they are finally completed, they often do not include all the functions and features needed to accomplish the business' objectives.

This results in frustration, substantial re-programming, delays and additional cost.

You see this happen time and again, but don't understand why - much less what can be done about it.

Solution #1:  Understanding The Major Reasons Things Continue to Go Wrong With Computer Projects.

1. See the Iceberg diagram above.  The software is only the visible part.  There is an enormous amount of additional work that must be done correctly.  Even with the best of intentions, IT people cannot do most of the work in the Iceberg.

2. IT is a young industry.  IT people continue to be focused on their technology and their concerns - rather than the needs of you, the business end user.  IT's business practices are sloppy, immature and full of waste.  IT people will eventually have to become more effective and better at producing results for business people - but it won't happen this week.

3. Statistics and the Management Literature tell us this will be a problem for a long time.  50% of all computer projects turn into Horror Stories.  Only 30% are completed something close to on time and on budget (if you are generous.)  CIOs (Chief Information Officers) change jobs about every 18 months.  Would you be changing jobs every 18 months if your department was performing as promised?

4. Who Pays?  The Kid in the Candy Store Problem.  Often, there is a very poor connection between how IT money is spent and results needed for the business.  We often see under-funded IT departments trying to please too many people.  We also see screaming matches over who gets priority, and some departments that demand "all the candy."  IT departments will continue to disappoint most of their customers until a rational connection between cost, business results and IT activities is established.

5. You would never tolerate this performance from a vendor.  You are IT's captive customer.   As in all monopoly situations, you, the customer suffer - yet you generally can't fire your IT department.  You may have tried to do some things on your own, but you rapidly discovered that there was an "iceberg" of work to be done...

6. This is not all the IT department's fault - but you are still stuck with the problem.  The IT department will complain about understaffing, over work, lack of money, constantly shifting priorities, business people not appreciating what they do, business people not being available to do their part and a host of other problems.  None the less, you are still stuck with computer projects that are late, over budget and don't perform as expected.

Solution #2:  Overview:  What You Can Do About These Continuing Problems

1. Accept the fact that this problem will not get better on its own - You must act.  You must chose to invest the time, money and effort necessary to bring your project to a successful result - or you will pay the price in the form of late, over budget software that doesn't perform as promised.

2. The good news is that there are many things you can do to help make sure your project comes in on time, on budget and as promised.  The bad news is they cost time, money, effort and will probably upset some people (IT department and others).  The additional good news is that, by doing the things identified below, the overall cost of the project will be lower than if IT continues to do things "the old way." 

3. Focus your attention on the highest payback, most important efforts.  After studying your own operations through process mapping, you will discover areas where a little bit of help from IT will produce big paybacks.  You will also discover areas where a big IT project will produce enormous results.  You want to focus your efforts on these high impact projects to help you get through the necessary cost and internal squabbles.  If your project has a very high payback, and is in line with senior management's top priorities, you have a far better chance of getting what you need to get the job done.

4. Pick your team, and give them what they need to get the project done right.  Review the Iceberg above and the lesson on building your team below.  The simple fact is that, if you need your software done right, you and your team will have to take hold and  "wrestle it to the ground".  The rest of these lessons will help you understand how.

5. Discipline, focus, diligence, accountability:  As you review the lessons below, you will notice that they center around having your people, and the IT people, work together on a disciplined, focused, diligent basis.  You will notice a number of accountability mechanisms.  These are essential business disciplines which IT efforts usually lack - and our purpose is to help you and your people learn how to insist on these disciplines.

6. Things will get better - if you do your part.  Your first project using these new disciplines will be difficult.  You can expect some resistance - even anger.  You will find, however, that after this project comes in on time, on budget and as promised, the next one will be better.  So will the next one and the next one.

7. Watch out for the common mistakes and traps.  Review the lesson below on "major traps and mistakes to avoid."  You can probably think of half a dozen times when you have seen these mistakes made.  These disciplines, properly executed, will prevent these mistakes.

8. Assess your IT department.  Do they really know what they are doing?  See the lesson below on "How to Know If Your IT Department Has Its Act Together".  If they do, you will see evidences of these disciplines in place.  Odds are, over half of them will be absent or ineffective.  Our purpose is to teach you how to fill in those gaps - to help IT get it right - the first time.

Solution #3:  Short Version:  How to Oversee Another Department (IT) or a Contractor that You Are Dependent On

1. You must have a mandate to hold the other party accountable.  Your boss or higher ups must be willing to tolerate the "friction" that will be caused by you requiring the other department to specifically spell out what they will provide and holding them accountable.

2. You must help them build an effective project plan (usually they won't do it themselves.)

3. You must decompose and strengthen the project plan until you are confident that the work is fully understood, and that they have the ability to complete the work as promised.   (They will resent this.  Worse yet, you probably won't have the expertise to do this - you will probably need some help.)

4. You must meet with them weekly to get status and hold them accountable for accomplishing what they promised to do each week. (Earned Value is a great measurement tool.)

5. The above steps are time consuming, involve cost, annoyance and friction.  The only thing worse is the performance you will get out of the other department or 3rd party if you fail to take this oversight responsibility.  The unfortunate reality is that most IT departments are not good providers of IT services - and most user departments are not good consumers of IT services.

Solution #4:  The "Undoable Job" Problem, Recap of Your Responsibility to the IT Department.  You Owe Your IT Department a "Doable" Job - The IT Oversight Committee

1. Remember that, generally, your IT people are competent and trying to do the right things.  The symptoms and problems you encounter are largely due to things beyond their control.  You (meaning the Business Units) must take responsibility for seeing that they have a "doable job."  Hint:  If you see a pattern of reasonably competent and  committed IT people being unable to satisfy the demands of the business units, you know you have the "undoable job" problem.

2. Why Your Organization Needs an IT Oversight (or Steering) Committee Reporting to the Board of Directors or Top Management.  Remember that you are in a situation where the IT department cannot fix the problem alone and you (the business units) cannot fix the problem alone.  The "IT to Business Unit" oversight methods in your organization are not working.  You must recognize the problem and act.  SEE THE JOHN ADAMS HISTORICAL NOTE BELOW.

3. Key Responsibilities of the IT Oversight (or Steering) Committee.

• SET PRIORITIES:  The business units must give the IT department a set of priorities based on value to the business and cost trade offs.

• PRIORITIES SET ON OBJECTIVE "COST VS. VALUE" CRITERIA:  Resist the common trap of setting priorities based on who screams the loudest, who can influence top management, who can schmooze the best, etc.  Unless some objective criteria are established (and stuck to), you will be forever stuck with the problems of subjective prioritization.

• RESIST TEMPTATION TO CHANGE PRIORITIES:  These priorities must be well thought-through and cannot change with every whim of a senior manager.  The cost of continual change of priorities and direction is devastating.  A sign of effective management is that, once established, these priorities remain constant for six months to one year.

• COMMUNICATE THESE PRIORITIES AND THE REASONING to the affected groups.

• COMMUNICATE CHANGES TO PRIORITIES AND THE REASONING to the affected groups.  Priorities will change and the IT oversight committee must take responsibility for communicating the impact.  IT IS CRITICAL TO COMMUNICATE THESE CHANGES TO THOSE PEOPLE WHO WERE EXPECTING SOMETHING BY A CERTAIN DUE DATE.  This is often unpleasant duty, but it must be done - the consequences of failure are skepticism, frustration and continual conflict between IT and the disappointed business units.

• REQUIRE THE BUSINESS UNITS TO DEMONSTRATE THE DESIRED OUTCOME AND HOW THE NEW PROCESS WILL WORK PRIOR TO ALLOWING IT TO ACCEPT THE PROJECT OR COMMIT TO DEADLINES.  Business unit will do this with process flow charts, screen mock-ups, business process modeling software, demonstrating the process manually first, providing adequate use cases and test data, etc.

• REQUIRE IT DEPARTMENT TO CREATE WORK PLANS BASED ON THE "40 HOUR RULE" PRIOR TO AGREEING TO A DUE DATE.  These work plans must break down the work into tasks no larger than 40 hours which can be signed off as "complete" by a representative of the oversight committee.  

• BE THE SOLE AUTHORITY FOR SCOPE AND DATE CHANGES.  Remember that whenever a change is accepted, other things are probably going to get delayed, and the IT oversight committee must communicate the impact of those changes to the affected groups of people.

• REQUIRE IT DEPARTMENT TO PROVIDE REGULAR STATUS REPORTS IN AN AGREED UPON FORMAT AND LEVEL OF DETAIL, BASED ON THE 40 HOUR RULE.  This is a difficult, but necessary step.  An IT oversight representative must be able to assess the completion status of every 40 hour task and report that status to the oversight committee.

• (STRONGLY RECOMMEND) THAT IT OVERSIGHT COMMITTEE MEET WEEKLY AND PUBLISH A ONE PARAGRAPH STATUS REPORT ON ALL PRIORITIES TO THE AFFECTED GROUPS.  The IT oversight committee has a lot of work to do.  They will not want to take the time to meet weekly, but they must (or you will slip back into the old pattern of problems and dysfunction.)  By committing to publish status on all priorities weekly (good news or bad), the oversight committee will solve the problem of keeping everyone informed as priorities change.  The committee’s weekly status report should report the facts, in a contributory, positive manner – but  honestly disclose the true status.  Status might include original due date, "risk weighted due date", reasons if behind, factors beyond people’s control, etc.  This may be an unpleasant task, but the consequences of not truthfully disclosing status are far worse.

• BE VERY CAREFUL AND DELIBERATE ABOUT PUBLISHING DEADLINES AND WHAT WILL BE DELIVERED BY THOSE DATES.  Generally, those that do the work must set the completion dates.  A “risk factor” that helps allow for the things out of people’s control can be useful.  e.g. if a project is due in 60 days and has a risk factor of 1.3, then, if the project is completed within 60 to 78 days, it is designated “on time.”

• HOLD ALL PARTIES RESPONSIBLE FOR PERFORMING AS PROMISED, TREATING EACH OTHER WITH PROFESSIONALISM, RESPECT, COOPERATION AND COURTESY.  The old pattern is that each group blames the other for incompetence, lack of caring, bad motives, personal agendas, etc.  The new pattern needs to include trust and cooperation beyond department boundaries.  It needs to include setting reasonable expectations and meeting those expectations - or providing advance notice that the expectation or due date will not be met.  The new pattern needs to include extending consideration to other groups when deadlines slip due to factors beyond their control.

• REQUIRE ALL PARTIES TO ADHERE TO CONFLICT RESOLUTION RULES.  For example, those lodging complaints will be asked to first go to the responsible person or department head and clearly state “here is my need – how can we work together to get this need met?”  If the need is still unmet, the complaining party, the responsible person or department head meet with a representative of the IT oversight committee to discuss the problem.  Both parties present their side (in the presence of each other) and the IT oversight committee takes necessary action to resolve the problem.  If the above process is not followed, the person or group who is the subject of the complaint has no responsibility to act until the above steps are taken.

• KEEP MINUTES AND LOG SUBSTANTIVE COMPLAINTS AND PROBLEMS

The above responsibilities and guidelines may seem unattainable, but there is no doubt that they will help resolve the traditional IT department - business unit conflicts.  To my knowledge, no other mechanism will resolve this difficult problem.  The alternative to the above is to continue to live with the status quo of dysfunction, waste, stress,  frustration and loss of competitive advantage.

DON'T FALL INTO THE TRAP OF HAVING THE IT OVERSIGHT COMMITTEE REPORT TO THE CIO, CFO OR TOO LOW IN THE ORGANIZATION!  Top management and the board of directors (generally) will resist having the IT oversight function report directly to them.  Understandably, they prefer to spend their time on other priorities.  Think through the above IT oversight committee tasks.  Can these be effectively accomplished by a group that reports lower in the organization?  The answer is no.  The simple truth is that the authority of the board or top management is necessary to bring the organization together around these tasks.  The board or top management simply needs to suck it up and attend to this responsibility.  Failure to do so will condemn the organization to the status quo of dysfunction, waste, stress,  frustration and loss of competitive advantage.

Historical Note:  Why John Adams would say "This is NOT the IT Department's Fault!"

In "The Portable John Adams" by John Patrick Diggins, pages 292 to 309, John Adams is quoted as to why dozens of republics have failed to endure throughout history.  Adam's observations were essential to shaping the great republican government experiment which became the United States.

Adams explains that the previous republics all evolved into two branches of government (or factions), which is an inherently unstable arrangement.  "We have all along contended that a simple government ... must, of necessity, divide into two [branches], ... and will proceed from debate and controversy to sedition and war."

He continues to explain why a third branch is necessary.  "Having no third order to appeal to for decision, no contest could be decided but by the sword."

These republics all descended into war and atrocities, and passed away.  Machiavelli and other historians blamed the problem on bad conduct by the people.  Adams disagrees, saying "Machiavelli's severity ought, however, to have been applied to the form of government, not the temper of the people.  The latter being but the natural and necessary effect of the former."

The writer of this book goes on to say that "Adams ... believed a revolution had no means of  enduring without the rule of law...  Adams was convinced that unless the country's political institutions were properly constructed, with a sufficient role for a strong ... president - America was doomed to go the way of all republics.."

If Adams were alive today, and faced with the continuing problems that we see between IT departments business users, I believe he would say, "This is not the IT department's fault - it is a defect in the government of the IT-to-business unit relationship. 

This relationship needs a third branch, backed by a strong set of governance guidelines. 

Without such an arrangement, you will continue to struggle and fight and blame each other as either uncommitted or incompetent"

What You Are Promised vs. What You Get

Impact of Failed Computer Projects On Earnings

Summary Table Showing Millions Wasted on Bad Computer Projects

Software Company Non Performance from A New Model for Software Company Investing

Computer Projects Fail 50% - 70% of the Time - Why? Research Summary

Understanding How To Improve Computer Project Outcomes

Solutions:

Effective Organization and Oversight Models

Discuss Case of IT Dept Overworked by 100%

Discuss the Stair Step Model of Normal Cost and Delay

Earned Value Training Materials 

Discuss TIA Project Turnaround Contract

DISCUSS CASE OF SERVICES COMPANY  INTERNAL DEPARTMENT FRUSTRATIONS AND SOLUTIONS

Effective Organization and Oversight Models

2

How to Document Your Business So That Your People and IT Can Make the Needed Improvements.

• Why do we need to map out processes before developing or buying software?

• Review actual case of Specialty Retailer.

• Review the Process Inventory for the Specialty Retailer.  How could anyone possibly implement a system to address all these processes simultaneously?

• WHO SHOULD DO THE PROCESS MAPPING?  The primary responsibility will fall to your people, assisted by IT.  If possible, include customers, suppliers and other departments in the mapping effort.

• MAP THE "AS-IS" PROCESSES.

• STAPLE YOURSELF TO AN ORDER:  You will need to map out every type of order (or transaction) that the new process must handle.

• FOCUS ON THE CORE PROCESSES that your customers pay you for.

• ASSIGN PROCESS OWNERS.

• MAP THE "TO-BE" PROCESSES.

• IDENTIFY THE RIGHT METRICS TO DEFINE PERFORMANCE FOR THE NEW PROCESS.

• Exercise:  Discuss a project you have in mind.  Think through the WHO & HOW of the responsibilities discussed above.  Think through the Process Inventory.  How many processes can you identify?  Which should be prioritized?

Newsletter 5 AS IS Master Flowchart

Newsletter 5 TO BE Master Flowchart

Review Most Recent AS IS Flow Chart from Large Services Company Project

Review Most Recent TO BE Flow Chart from Large Services Company Project

Review Most Recent Metrics Model from Large Services Company Project

Review Score Card Metrics for City of Carrollton

Discuss Drucker's 5 steps for improving service productivity from "The New Productivity Challenge", Harvard Business Review, November/December 1991

See article "Staple Yourself to an Order", by Shapiro, Rangan, and Sviokla, Harvard Business Review, originally published in 1992, Republished in Top-Line Growth, July-August, 2004.  Generally available online through your public library.

3

How a Single Document Can Specify Everything You Need (Requirements, Screens,  Training, Testing and Sign-Off.)

• DO NOT LET THE PROJECT PROCEED WITHOUT PROCESS MAPPING.  It helps you understand what you need, so you can communicate it to IT.  This is the basic building block of your Requirements Document.

• DON'T BE INTIMIDATED by techno-jargon and bright young people who think they know what they are doing.  Insist on documents and discussions that make sense to you.

• Review the case of the Specialty Retailer.

• A SIMPLE EXAMPLE OF "SCREEN FLOWS" as the tool to identify all the screens that are needed.  Review the Texas Instruments Accounts Payable Case.

• A COMPLEX EXAMPLE:  Review the "STORYBOARD" used to help define the screens in Newsletter 10, the complex internet project.

• "USE CASES" as tool to translate your order types into software.  Review the use cases described in Newsletter 10, the complex internet project.

• ANOTHER EXAMPLE OF A REQUIREMENTS DOCUMENT:  The Dallas Consulting Company Software Case. 

• EXAMPLE OF INCLUDING TEST DATA IN THE REQUIREMENTS DOCUMENT:  Review  requirements document for the Specialty Retailer.

• CONVERSION OF DATA FROM EXISTING SYSTEMS:  The Requirements Document also needs to define how the data in your existing systems will be cleaned up and transferred to your new system.

• SUMMARY:  The REQUIREMENTS DOCUMENT CONTAINS Screen Flows, Use Cases, Acceptance Testing Data - All in a format suitable for user training!

• INSIST ON THE REQUIREMENTS DOCUMENT BEING WRITTEN IN PLAIN ENGLISH

• INSIST THAT THE REQUIREMENTS DOCUMENT INCLUDE EVERYTHING NEEDED TO CONDUCT USER TRAINING ON THE NEW SOFTWARE.

• DO NOT ALLOW THE PROJECT TO PROCEED UNTIL YOU UNDERSTAND THE REQUIREMENTS DOCUMENT AND SIGN OFF ON IT!

• Exercise:  Discuss current project(s) under way.  How would you approach doing these projects based on this model?

Newsletter 10 Master Flow Chart

Newsletter 10 Use Cases

Newsletter 2

Newsletter 2A

Screen Flow Use Case Example Simple

ScreensFlowSimple WithSignOff.pdf

UseTestCasesSimple.pdf

Sales Use Cases Specialty Retailer

Use Case Screens Detail Bid Package

4

How to Develop a Cost / Benefit Justification

• What barriers do you run into in quantifying the value of software projects?

• Understanding the Fundamentals of Why Companies Spend Millions on Computer Systems

• The HOTFOOT Method of Quantifying the Value of Computer Projects

• Three examples of business case cost / benefit analysis for software projects

• Exercise:  Quantify the value of a project you are working on (or two)

Requirements Log With Business Case

Business Case Payback Examples 1

Business Case Payback Examples 2 (best, password required)

5

How to Assemble the Right Team and Give Them What They Need

• FOCUS:  Avoiding the trap of trying to do too many things.

• ASSEMBLE THE TEAM:  Understand the roles needed, who is needed outside your department, how to pick the right people.

• GIVE THE TEAM TIME TO DO THEIR WORK:  Understand the magnitude of their task and that they are probably doing the work of two people already.  Give them some relief from current responsibilities so they have time and energy to do the work right.

• THE IT PEOPLE MUST HAVE TIME TO DO THEIR PART.  This is particularly a problem, since IT tends to have too many demands placed on it.  See the lessons on cost justification and estimating and planning to help make sure IT will be able to make its people available.

• TRAIN THE TEAM:  They need to learn from success stories and failures.  They need to understand their role.  They need to believe this will not be one more "program of the month".  They need a sense of what might be possible.  They need to make the project their own.

• INCENTIVES:  The team needs to be rewarded (formally or informally) for the improvements that they help make.  Explicit, measurable incentives are the best - and they need not be large.

• FEAR OF JOB LOSS:  The project may result in some people losing their jobs.  If team members do not have some guarantee of a job elsewhere, it is nearly impossible to accomplish the big cost reductions and productivity improvements you are looking for.

• Exercise:  Discuss a project where the right people were not on the project.  What was the impact and what might have been done to prevent the situation?

FOP JOPP RUAT SEAT

Informal: Newsletter 5

Formal: Services Company  Project Priorities List: Project Priorities Dots Quick Hits (password required)

Business Case Payback Examples 2     (best, password required)

Discuss most recent results from reorganization, office consolidation for Large Services Co.

6

How to Identify and Make the Needed Policy Decisions

• THE BARRIERS AND ISSUES LIST:  Make sure your people accumulate a list of issues and barriers to the success of the project.  These will point you toward the policy changes you need to address.

• DO THE POLICY DECISION THINK-THROUGH EARLY ON:  It may be that policy decisions needed to make the process work are beyond your power to change them.  It is best to identify these issues early and re-define your efforts so you can actually have the capacity to accomplish your goals.  (Many will view this, correctly, as compromising what might be accomplished.  This is true, but reality often leaves us with only the option of doing the best we can with what we have to work with.)

• THE COST / BENEFIT JUSTIFICATION is a helpful tool for persuading senior management to make the needed policy changes.

• OFTEN, THE CRISIS MUST COME:  Turnaround experts will tell you that they can often get things done in crisis situations which would be impossible in normal circumstances.    You may want to think about waiting until such a climate exists.

• Review excerpts from "Straight From The Gut" by Jack Welch.

• Review excerpts from "Who Says Elephants Can't Dance?" by Lou Gerstner.

• Review case of large services company - policy changes needed versus policy changes that various executives were willing to adopt.

• Exercise:  Discuss a project under way.  What are the tough policy decisions that need to be made?  Will they make or break the project?

Discuss Excerpts from Jack Welch book

Discuss Excerpts from Lou Gerstner Book

7

How to Define the Needed Jobs and Organization.

• DON'T REORGANIZE UNTIL THE WORK IS FULLY UNDERSTOOD.  Usually, the right organization becomes evident as core processes are better understood and measured.

• CONSOLIDATE THE WORK.

• CONSIDER "CASE MANAGERS" OR "CASE TEAMS".

• IDENTIFY AND REMOVE EVERY POSSIBLE HANDOFF BETWEEN DEPARTMENTS.

• WORK TO REDUCE THE HANDOFFS, CONTROLS, DUPLICATE INFORMATION AND DUPLICATE EFFORTS BETWEEN YOU, YOUR CUSTOMERS AND YOUR SUPPLIERS.

• DEVELOP JOB DESCRIPTIONS, PERFORMANCE MEASUREMENT AND EVALUATIONS

• IDENTIFY (AND FILL) THE MOST IMPORTANT JOBS FIRST - WITH YOUR BEST PEOPLE

• REVIEW BASICS OF INTERVIEWING AND HIRING THE RIGHT PERSON

• DISCUSSION OF ORGANIZING AROUND OUTCOMES, CUSTOMERS, PRODUCTS, GEOGRAPHY, TECHNOLOGY, FUNCTIONAL DISCIPLINES.

• Exercise:  Discuss a project under way.  What are the most important jobs?  What will it take to fill these jobs with the right people?  What is the right way to organize?

Discuss Job Descriptions and Organization Changes from Large Services Company Project

Discuss The "Grote Approach" to Defining Jobs and Improving Performance:  Use Case Screens Detail Bid Package

8

How to Quickly Document the Procedure Steps Your People Will Need With the New System

• WHAT HAPPENS IF WE SKIP THIS STEP?

• HOW TO QUICKLY DEVELOP A PROCEDURE BOOK FROM THE USE CASES IN THE SOFTWARE REQUIREMENTS DOCUMENT.

• UPDATING AND MAINTAINING PROCEDURES SO THEY REMAIN RELEVANT

• USING WALL CHARTS TO REMIND PEOPLE AND MAKE IT EASY TO FIX THE PROCESS INSTEAD OF WORK AROUND IT.  Your people can easily see how things should be working, and write needed process changes directly on the wall chart.

• Review Requirements Document from Texas Instruments AP case.

• Review Use Cases from large internet project.

• Review footnotes in Requirements document for Specialty Retailer - forms the basis for procedures.

• Review the Process Inventory for the Specialty retailer.  Think through the magnitude of procedures that have to be written or updated for the new system.

• Exercise:  Discuss a project currently under way.  Identify the major procedures that will be needed by thinking through the process inventory.

Newsletter 10 Use Cases

Process Inventory Specialty Retailer

Discuss Procedures Defined and Developed for Large Services Company Project

9

How to Help IT Make Sure They Haven't Forgotten Anything.

• Review three examples of Earned Value Estimating and Planning.

• WORK BREAKDOWN:  Require that the work plan for the project is broken down into tasks that are no larger than 80 hours.  No exceptions!

• SIGN-OFF BEFORE PROGRAMMING STARTS:  Require that a knowledgeable third party review the work plan and requirements document for completeness and the ability to maintain accountability - prior to the start of programming!

• ESTIMATING CHECKLIST:  Require IT to address each item in the estimating checklist to the satisfaction of a knowledgeable third party before approving the estimate.

• INDEPENDENT SIGN-OFF:  Require that your people, or a third party, can independently sign-off on the completion of each task.

• REQUIRE IT PEOPLE TO BE AVAILABLE TO PERFORM THEIR WORK:  The Earned Value method of project planning and oversight will help you keep on top of this problem.

• Exercise:  Discuss a project that wasn't estimated correctly.  What were the key things that were left out?  What caused the overrun / delay?

SimpleProjectPlanTesting TooLow.pdf

Newsletter 15

Earned Value Training Materials 

Project Plan Checklist

10

How to Make Sure IT Stays On Track for an On time, On Budget, As Promised Delivery.

• Review three examples of Earned Value Estimating and Planning.

• EFFECTIVE WEEKLY STATUS REPORTS:  Require weekly status reporting of work accomplished against plan.  These reports must show the status of completed work - not just activity.

• PAY ONLY FOR COMPLETED WORK:  Authorize payments or chargebacks only for the completion of planned work, and only for planned amounts.

• DO NOT ALLOW CHANGES TO DILUTE ACCOUNTABILITY:  See the section on managing changes for how to allow changes in a controlled fashion, without compromising accountability for completing on time, on budget, as promised.

• FORECAST ACTUAL COMPLETION DATE AND COST:  The Earned Value method will allow you to forecast how long it will take and how much it will cost to complete the project.

• KNOW WHEN TO STOP THE PROJECT:  If the IT department is not consistently completing work as planned by the 20% complete point, it is time to stop the project.

• Exercise:  Discuss a project under way.  What are the strengths and weaknesses of the current status reporting.  What needs to be improved?

Sample Action Items, Issues and Minutes Log

Stat Rpt Showing Cust Resp and Failure

Earned Value Training Materials 

11

How To Address Changes, But Maintain Accountability for On Time, On Budget Completion

• Review three examples of Earned Value Estimating and Planning.  Discuss how changes are managed.

•  WORK BREAKDOWN:  Require that changes are estimated and approved in no larger than 80 hour tasks, which are independently signed off for completion.

• CHANGE PROCEDURE:  Require that changes are incorporated into the total project budget and schedule.

• UPDATE THE REQUIREMENTS DOCUMENT:  Requirements for the changes must include the same essentials discussed above for all other aspects of the software.  (Screen Flows, Use Cases, Acceptance Testing Data - all in a format suitable for user training.)

• Exercise:  Discuss changes being proposed for a project currently under way.   What should be done to make sure the changes are handled effectively, and accountability is maintained?

• A positive example:  Two small projects encounter technical problems and significant changes yet come in on time and on budget.

Discuss Change Order Forms

Discuss Customer Failure to Have Baseline from Which to Manage Changes, $5 MM Fraud Newsletter 21

TIA Earned Value Article

Earned Value Training Materials 

12

How to Make Sure The Bugs are Worked Out Before You Accept The Software.

• Review what needs to be included in the Requirements Document, especially Use Cases and Acceptance Test Data. 

• Do you need to conduct a parallel test?

• Require that your IT department demonstrates how the software handles each Use Case and each item of Acceptance Test data for all of the types of orders (or transactions) that your software must support.

• Require Acceptance Testing to be completed prior to sign-off for completion or payment.

• Require your IT department to capture bugs and trouble tickets in a system, and report their resolution in a controlled manner.

• Capture lessons from Acceptance Testing to update procedures and user training.

• How a trouble ticket tracking system saved a $2 million project - Insurance company case

• City Government Test / Fix Process that resulted in a 25% reduction in testing time

• Exercise:  Discuss a project currently under way.  What will be the essential steps in testing?

Newsletter 10 Use Cases

UseTestCasesSimple.pdf

Sales Use Cases Specialty Retailer

Use Case Screens Detail Bid Package

13

How to Go-Live On the New System Without Killing Yourself or Your People.

• TRAINING FOR YOUR PEOPLE:  Develop your training from the requirements document and Acceptance Testing

• PREPARE TO GO LIVE:  If you have done the above, you are well prepared.  Expect some difficulties and long hours.  Offload work from your key people so they have some extra time.  Think through logistics of deploying hardware, software and communications to all those that will use the system.  Train your people.

• CONVERT DATA:  In many cases you will need to convert data from old systems or manual records.  These issues should have been identified and addressed early in the process.  This step is often overlooked and troublesome because you usually have to convert the existing data into a format that your new software can use.  It is also troublesome because the old data often has errors that must be corrected - otherwise the new system will continue to perpetuate the same errors!

• PILOT PROJECTS:  In most cases, you will want to conduct a pilot project on a small scale before attempting to implement the new software on a large scale.

• GO-LIVE!

• Exercise:  Discuss a project currently under way.  What are the key tasks needed to get ready to go live?

Newsletter 10 Use Cases

UseTestCasesSimple.pdf

Sales Use Cases Specialty Retailer

Use Case Screens Detail Bid Package 

Discuss Case of Xerox Conversion

Discuss Large Services Company Prep, Convert, Pilot, Go Live

14

• THE NIKE TRAP:  "JUST DO IT!"  Just declaring that the project will happen and charging ahead (without a detailed understanding of WHO will do WHAT by WHEN.)

• THE BIG BANG:  Trying to tackle too much, instead of breaking the project up into manageable chunks.  (See the Process Inventory for the Specialty Retailer.) 

• ASSUMING THAT SOMEONE ELSE WILL DO ALL THE WORK that only your department can do.  The IT department is often expected to create systems for business processes that they do not understand.  Your department needs to take the lead in defining the desired new process and ensuring that a written specification exists for what the IT department will produce.  Only your business people can do this - and we have all seen the folly of relying on the IT department to do something beyond their capabilities or interest.

• NOT COUNTING THE COST:  Not thinking through "Who pays for What and How?  Is this justified?  Is the payback high enough to warrant the risk, time and investment?  Will this project generate enough cash flow to justify proceeding?"

• STARTING WORK and BURNING MONEY BEFORE REQUIREMENTS ARE DEFINED:  Allowing programmers to begin work before the Requirements Document has been signed off.  (Thinking that this will speed things up - when it actually slows things down because of all the rework.)

• NOT DEFINING HOW YOU WILL VERIFY THAT THE SYSTEM IS DONE RIGHT:  Not including acceptance testing data in Requirements Document

• PAYING FOR ACTIVITY INSTEAD OF WORK ACCOMPLISHED:  Paying programmers or vendors based on time spent rather than proof of work accomplished.

• TOO MANY PROJECTS - Your department is tackling too many priorities at once

• TOO MANY PROJECTS - The IT department is tackling too many priorities at once.  The Hewlett Packard Case:  "We starve all projects equally".  Discuss case of Florida Manufacturer.  The Work Breakdown Structure / Organization Breakdown Structure Method for Identifying Problems and Persuading Management to Act.

• PEOPLE OVERWHELMED:  Expecting your people to put in the time and energy required on this project in addition to the three jobs they are already doing.

• JUST REORGANIZING without specifically addressing underlying work issues and problems.

• LACK OF INCENTIVE:  Failing to give your people a real incentive to improve.

• JOB FEARS:  Failing to address the fear of job loss.

• IT PEOPLE NOT AVAILABLE:  Not planning, estimating and managing the project such that IT people are held accountable for doing their work on time.

• LACK OF ACCOUNTABILITY:  Accountability can be destroyed by (a) failing to define the desired outcome sufficiently in a Requirements Document, (b) allowing changes to be made without redefining accountability or (c) allowing work to proceed without a control or sign-off on work being accomplished according to plan.

• CHOOSING TO HOPE INSTEAD OF LEARNING FROM HARD EXPERIENCE.

• BACKED INTO A CORNER:  "I GOTTA HAVE THAT SYSTEM!"

• SEDUCED BY THE SIREN SONG OF SOFTWARE VENDORS AND CONSULTANTS

• Exercise:  Discuss a project that got into major trouble.  How many of these traps were encountered?  What might have been done to prevent this?

Earned Value Training Materials 

Process Inventory Specialty Retailer

Review Iceberg Model

OBS WBS Major Swr Release Plan

Discuss Starting Work, Looking Busy, Burning Money, $5 MM Fraud Award Newsletter 21

Discuss Case of Large Services Co., IT Dept Continually Criticized with "It Doesn't Work."

Discuss Case of Florida Manufacturer

Formal: Services Company  Project Priorities List: Project Priorities Dots Quick Hits (password required)

Business Case Payback Examples 2 (best, password required) 

Stat Rpt Showing Cust Resp and Failure

Discuss Case of French National Railway

Discuss Advanced Internet Project Case - $750,000 to $17 million at stake Newsletter 10

15

Key Lessons from Large Reengineering Projects

• An inside look at a very large reengineering project

• Quick Hit Projects, Medium Hit Projects, Longer Term Projects

• Review two "AS-IS" Process Flows for a large reengineering project

• Exercise:  Describe the symptoms that are probably present, based on these flows.  What should be done?  What are the biggest potential pitfalls?

• Review time study / process efficiency findings to see why 100% to 500% improvement is possible

• Review two "TO-BE" possible solutions to process flow problems

• Large Services Company Case, (cont.): Mapping out 5 field operations

• How we reduced enormous complexity to 15 types of orders (or transactions).  This was  what customers paid the company for.  Reengineering the company became a simple matter of continually improving these 15 core transactions - everything else was secondary.

• Review list of hard, unpopular things that may be necessary in order to accomplish the organization's objectives.

• Exercise:  Discuss a large reengineering project.  What went right?  What went wrong?  What lessons from this discussion might have helped?

ProcessFlowASISLargeServices CoDiv1A.pdf (password required)

ProcessFlowASISLargeServices  CoDiv2.pdf (password required)

TimeStudyProcessEfficiency Detail.pdf (password required)

TimeStudyProcessEfficiency Summary14Projects.pdf (password required)

ProcessFlowTOBEServices CoMultipathDraft2.pdf (password required)

Review Large Services Co. Field Operations AS IS chart

Review Large Services Co. Field Operations TO BE chart

Tough Unpopular ThingsThat May Need to Be Done

16

If Your IT Department Is On The Ball, Most of the Following Will Be Evident In Their Work:

• Action Items Log and means of making sure action items are completed on time

• Issues Log means of making sure issues are resolved

• Meeting Minutes

• Status reporting mechanism that reports on planned work accomplished, not just activity

• "AS-IS" and "TO-BE" Process Maps

• Detailed Checklist for Requirements Documents

• The "Out of Scope" List which documents what we agree not to do

• Detailed Checklist for Planning and Estimating Projects

• Detailed Checklist for making sure that Customers, 3rd Parties and affected departments all understand and adhere to their responsibilities

• Checklists for detailed technical design and technical issues

• Detailed Checklist for planning and converting data

• Detailed Checklist for preparing for "GO-LIVE"

• Procedure for identifying and resolving project risks

• Detailed Checklist for conducting software testing

• Detailed Checklist for conducting Acceptance Testing

• Bug-Fix, Trouble Ticket Tracking System

• Release Planning mechanism for breaking large efforts up into doable chunks

• Tracking system that records time and charges it to specific, measurable tasks so accurate status and cost can be reported

• Software Development Standards

• Quality Assurance oversight procedure

• A "Project Portfolio" that defines the total workload the department must handle and how it will be addressed

• A rational, effective means of prioritizing WHAT work is to be done WHEN.

• Checklists and procedures that make sure that the often overlooked items get addressed (Security, Disaster Recovery, Backup, Documentation, Stress analysis, testing, performance under load, managing maintenance and downtime, restricting access for legal or HR reasons, Default values in fields, etc.)

• Exercise:  How many of these disciplines are present in your IT department?

Out Of Scope List

TeamGuidelines.pdf

Newsletter 15

Newsletter 2

Newsletter 2A

Stat Rpt Showing Cust Resp and Failure

Customer Contract Checklist

Other Dept Checklist

Third Party Resp Checklist

Functional Specification Checklist

High Level Design OOM Estimate Checklist

Detailed Design Checklist

Production Cutover Checklist

Project Plan Checklist

Risk Management Checklist

Test Plan Checklist

User Acceptance Checklist

17

The Special Energy and Momentum Generated by Cross-Department, Cross-Company Cooperation.

• Fundamentals of cross-organization teams and workshops

• Texas Instruments Accounts Receivable Case

• Outsourcing Firm Case:  establishing a standard workshop for Energy industry clients

• Adding Customers and Suppliers to Cross-Functional Workshops

• Services Company New Client Process Case

• Exercise 1:  Practice interactive project planning on a current project.

• Exercise 2:  Draft the agenda for a workshop for a current, complex project

Software Implementation Workshop

Flowchart for Bringing New Client On Board  (Confidential, Password Required)

Workshop for Bringing On New Clients (Confidential,  Password Required)

Review Project Plan Developed for Large Services Co. Consolidation of Field Operations

18

• Defining the reporting problem in business terms:  What is the key information that the business user needs?

• Why you want to define the reports up front

• Review how process mapping tools and RUAT approach helps you quickly and correctly identify reports needed

• Specialty Retailer Case

• Consulting Company Case

• Exercise:  Create a checklist of all the things you want to remember to consider when defining reports

• How do you know if the data is present?

• Triggers

• Formatting

• Error handling

• Sorting

• Searching / selecting

• User tools for writing your own reports:  Pros & Cons

Use Case Screens Detail Bid Package

Review Engineered Air Balance Case Newsletter 14

19

• Exercise 1:  Begin the session by starting a checklist of everything you should watch out for when dealing with third parties, software vendors and consultants.

• IT Outsourcing Firm Case Part II

• Dallas Manufacturing Company Case Part III

• Complex Internet Project Case Part III

• Case of large Midwestern bank

• Exercise 2:  Validate your checklist against the items raised in discussion.  How did you do?

• Exercise 3:  Think through the previous lessons.  How would you prevent this from happening to you?

• Large Transportation Services Company Case Continued:  How to purchase a very large software package or software development effort

• Specialty Retailer Case Continued:  A more effective software specification for purchasing package software enhancements

• Dallas Consulting Company Case Continued:  A very effective bid package for the development of complex software

Customer Responsibilities Due Dates Checklist

Customer Contract Checklist

Other Dept Checklist

Third Party Resp Checklist

Discuss $5 mm Project Turnaround Newsletter 3

Newsletter 10 Master Flow Chart

Sales Use Cases Specialty Retailer (just the software specs - full bid package detail to be added)

Use Case Screens Detail Bid Package

Bid Package Complete LMN Company

20

• Florida Manufacturer Case - 100% Over Booked!

• Large Transportation Services Company Case Continued:  Issue list showing how this large project was stalled for two years by unresolved issues

• Large Midwestern Bank Case Continued:  Issue list showing customer's failure to perform their responsibilities resulted in cancellation of a $4 million project.  How the issue list itself prevented a $4 million lawsuit.

• Building Cost / Benefit justification and business value

• Learning to focus on core processes and core value where line executives care about the results

• Exercise:  Discuss projects from participant's history.  Which projects were damaged by failure of customers or users to do their part?  What might have been done to avoid the problem?

Issue List No Resolution1 

Issue List No Resolution2

Stat Rpt Showing Cust Resp and Failure

Review Core Processes Models for Large Services Firm.  Discuss Ongoing Prioritization Issue Business Case Payback Examples 2 (best, password required)

21

• Exercise: Review the flow charts for field operations for Large Services Company.  Your goal is to simplify, prioritize and standardize on a set of best practices.  How would you approach the problem?

• Large Services Company Case Continued:

  • Initial time study showing how costs are accumulated for a particular type of order

  • Time study showing efficiency (and how related to cost) for 14 projects

  • Sample Costing Model for Large Services Company.  Shows how to sort through complexity to understanding key cost issues and help the business focus on the more profitable parts of the business.

Master Field Operations TO BE Chart

TimeStudyProcessEfficiency Detail.pdf (password required)

TimeStudyProcessEfficiency Summary14Projects.pdf (password required)

Sample Costing Spreadsheet Showing why costing is necessary to reduce complexity and prioritize correctly.  Shows customers, types of services performed, how company is paid and profitability for each cell in the spreadsheet.