Skip to main content

Author: William Myers

Importance of Small Projects

Developers generally want to work on the large project that will be the next big product or save the company.

However, small internal projects are the glue that pulls them together and supports daily operations. They make people’s lives easier and can potentially have a huge impact on the bottom line. Also, if managed correctly, they provide wonderful training platforms for new leaders and employees.


A small project may differ in the mind of management when the staff is 200 from one with a staff of 20. My first estimate after I joined EDS was in work hours. They were used to thinking in months and could not grasp how long the project would take. I had to change everything to days.

The definition of a small project here is work from one day to about 3 months as long as it has a Full Program Development Life Cycle (Definition; Analysis; Design; Construction; User acceptance testing; Implementation, Post implementation adjustments , Documentation) , but condensed to a reasonable size . Some organizations include Maintenance but that means that the project never ends. It can include more than one developer. I was once team lead for a 3-week project with 3 other programmers.

For example, EDS had a Large Service Request (SIR) requiring approval by coordinating committee, Small Service Request less than 60 development days requiring approval between the IT and Business manager, and a Standard One-Day Consultation SIR used for meetings and simple changes. I used the standard one-day SIR to create a database, complete with maintenance pages, reports and user manual, that coordinated production between two factories – 7 ½ hours. This can be done with the right tools. My manager did not know how to react. It was an entire system (“app” in today’s terminology). They passed a new rule that an entire system had to have its own SIR no matter how long it took.

Users don’t feel ignored

The most common complaint from users is that they are ignored by IT. One problem is that some organizations assign projects based on estimated ROI (Return on Investment). Small projects don’t normally show much ROI. However, completing a large number of small projects over the year really improves relations between the IT department and the user community.

Unforeseen benefits

I have found that ROI is unpredictable. In one case, I badgered my manager for two weeks to let me work on one monthly report generated by hand by one person. Finally, I was allowed to work on it after 4:00 PM each day. When complete, it highlighted to the group VP a pricing problem in one product line. When corrected, profits increased $2,000,000 the next year. My first project out of college increased the company’s share of the entire market by 20%. I have had others that just made people’s lives easier but had no measurable ROI.

In my latest position, I worked for a regional office of a publishing company. Excel spreadsheets were the main data entry platform for the database. IT management did not consider Excel to be a professional development platform. There was no test environment! So, while becoming familiar with the environment during my first two weeks, I added a toggle button to all of the workbooks. It changed the heading banners and the upload button to red, pointed to the test database, and warned the reporter that they were in test mode when they saved their data.

[widget id=”custom_html-68″]

Benefits of the new test environment:

  1. 1. Users could test changes without damaging production data (expected benefit)
  2. 2. I could copy a problem workbook to the test environment to fix problems during crunch time while the user continued working. Normally the reporter would stop work while the problem was being fixed (unforeseen benefit).
  3. 3. Management used it for training new staff (unforeseen benefit)

Similar projects have increased our credibility, found millions of dollars in savings, helped immensely with union negotiations and gotten OSHA off of our back.

Unforeseen risks

Although small projects may not be much in ROI, they can carry very high risks if they fail. In my article, “Don’t YOU be the Cause of an IT Project Failure”, the companies lost tens of millions of dollars. In all three cases, IT management changed the original project goal and directly caused the project failure.

Stopgap solution

Frequently, a short term project can be implemented to solve part of a business problem thus making user’s life easier while the mega project is being built. The users are usually grateful to get any help. Occasionally, the data collected by the small project was later used to populate the larger app. In one case, the Federal auditors required that the interim report be included as part of the final process.

New employee training

I used small projects to train new employees in the company’s business environment, technical environment and company culture. This will be the subject of a future article.

Support for Super Users

Some employees, i.e. Super Users, gain enough expertise to build their own support tools in Excel, MS Access or some other tool. I always provided expert advice and encouraged them to follow professional standards, such as documentation, user instructions and better techniques.

Benefits for IT:

  1. 1. New projects when they reach their limit of expertise
  2. 2. Provides a good starting point, easy transfer of knowledge
  3. 3. Test data for that new project


It costs too much for IT departments to ignore, or worse belittle, small projects. Just the relationship between IT and the user community can be jeopardized. They can benefit the company and themselves if even one or two people are allocated to small projects and the projects are treated in a professional manner.

Post implementation adjustments: Final implementation is not the time to go on vacation. Users will do things that the development team never dreamed of. Hidden design flaws and coding bugs may manifest themselves. Some will require immediate fixes. I usually allocate 5% of the construction time to these adjustments. Once through this phase, the project can be signed off.

Don’t YOU be the Cause of an IT Project Failure

I have never had a project that I was personally in charge of fail from 1969 to present. The average failure rate for new projects is 14% according to CIO magazine .

The article covered most things that can be done to avoid failure. However, they missed one major cause of failure. I witnessed three projects, each 15 years apart that failed due to the same cause – one IT management decision. A project can have only one primary goal . They changed the project goal from solving a business problem to implementing their own favorite technical or methodological solution. The costs were huge. Two could actually be measured.

These were small projects, hardly noticeable, but with a large impact. All three projects started by coding a proof-of-concept and user demo with live data. Time was included in the plan for adjustments based on user feedback and completion of the final project from the proof-of-concept. Management stepped in after the demo and transferred them to another team with instructions to rewrite the app. All three projects might have been salvaged if they had just discussed lessons learned with the prior team as highlighted by point #7 in my article “Innovation and Turmoil ” (Ask for help or advice. Ask an expert if there is one.).

Coding Methodology (most recent)

The main goal for the team was to add security to the prototype and present the app at a convention. The core structure they started with worked perfectly (one company said that it could not be done at all). The team argued constantly about how it was written, was unable to meet the convention deadline and quit without writing the security module. The security module itself would have been a partial success and could have been written however they wanted. The app had the potential to save many millions of dollars in medical research but never made it to market.

Platform (15 years ago)

The app was actually rewritten without looking at the prototype and put into production. Our company had 700 consultants on the customer’s site. The cost overrun was so large and implementation date was missed so badly that the customer VP was reprimanded in his review by the president for failing to kill it early on. After that, the customer, per contract, cut the maximum consultants on site (70) each year AND the consulting firm never received another new project. One consulting firm manager actually thought the app was a success in demonstrating object oriented technology.

[widget id=”custom_html-68″]

Computer Language (30 years ago)

The new team was unable to complete the project at all. I would have had it in User Acceptance Test within 2 weeks of the demo, but management wanted it converted to PL/1, the language that they understood. The app was requested by the division’s largest outside customer, the largest car battery retailer in the US at the time. One year later, the company lost that battery contract.

Inadvertent Comments

This was not a project, but it is related. The machine converting powdered carbon to pellets was leaking dust. The Senior VP was touring our plant. He said “Tighten up those seals.” The machine ground up the seals into the pellets. We had to scrap 12 million dollars of product. Luckily, our database was able to isolate by lot number the product produced by that production line from the other 5 lines. That one statement cost the company 12 million in profit that year.

None of the managers involved in the examples ever knew how much damage they did to their company or their customers. It is very easy to destroy a project by repeating history. Don’t confuse project outcomes with business outcomes . Always be careful what you say, pay attention to the small projects, and never forget the business goal.

“IT project success rates finally improving”, CIO, Sharon Florentine, Feb 27, 2017,
“The Reason Why Project Management Tools Won’t Help You”, Project Times, Dmytro Moroz, July 2018,
“In novation and Turmoil” Journal of Systems Management, William Myers, Dec 1987,