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.
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.
Benefits of the new test environment:
- 1. Users could test changes without damaging production data (expected benefit)
- 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. 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.
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.
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. New projects when they reach their limit of expertise
- 2. Provides a good starting point, easy transfer of knowledge
- 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.