If you have read any of my previous blog posts, you’ll know that I’m all about business process management and efficiency. For better or worse, I spend quite a bit of time thinking about how organizations produce work. A common framework for many businesses to produce software releases is to have both a capital projects and an expense (run the business) model. I’m not an accountant and don’t pretend to understand all the intricacies of
accounting rules, but I do know that generally accepted accounting principles allow for the capitalization of some software development costs as specified in Statement of Position 98-1.
Producing software is an expensive process when you consider fully loaded project costs to include design, development, testing, management, etc. Expecting a return on this investment and structuring the cost to capture its benefits over time is a natural course of asset management and a step towards proper performance and benefits for an organization.
With that said, organizations should also allow for maintenance of existing software through a more streamlined process. If organizational resources are completely dedicated to capital projects and production support then the overall software output cycle doesn’t follow a consistent release cycle and there are periods of time where some members of the organization are not fully utilized. If you think of your software development team as a machine or production line, then you want to keep each of the stations busy so that the throughput of the machine is optimized. Otherwise the system will have queued work in some stations while other stations starve for work.
I say all that to get to the main point of this post. If all of the software development activities are on full capital project timeline then members of the organization that try to move work quickly will become frustrated and look for ways to insert work into the system. In a formal project process this is typically a scope change request. The work may or may not be directly related to the original project objectives. It’s like “pork” going into a bill in congress. The organization members that are frustrated by this are members who interact directly the end customers. This could be customer service, sales, or marketing. As they listen to the voice of the customer they will naturally try to solve their business needs as a part of the value proposition and service of your company. Pork Barrel software really doesn’t benefit anyone. It’s frustrating for the project teams because they feel like scope creep is making their project longer. It creates project justification issues for Project Management Office because the financial analysis of the project changes. It frustrates the end customer because they feel like their needs are not met in a timely manner. The list goes on…..
If this is a problem for your organization, how do you solve it? At the core of the answer is that you have to allow for time to be used on capital projects as well as run the business activities such as maintenance, defect resolution, and architectural upgrades. A simple way to do this is to use a percentage base allocation system. So for example you might allocate 70% of time to capital projects, 20% to run the business, and 10% to administrative activities. Adjust the allocation as needed for your business.
What other methods have you used for resource allocation and allotment in your organization?
One Reply to “Pork Barrel Software”
Comments are closed.