Software Best Practices

I need some advice, folks.

Our firm was recently acquired. The new firm is seeking SOX compliance with an eye towards going public at some point in the future. To that end, they have hired a consulting firm to create a new SDLC for us, and they brought that SDLC to us, and have submitted it to us in draft form. The SDLC is intended to establish the process for all software projects, both in-house, and those we develop for our customers.

Upon viewing it, I was alarmed. First, it clearly spells out the waterfall method. Second, it spells it out in excruciating detail, to a level that creates vast amounts of bureaucratic overhead. It was clear to me, upon reading this plan, that it was intended for a company with a large software development staff. Our firm's software development staff consists of one software developer. (That's me.)

Now, I'm not opposed to process. Rather, I'm an ardent proponent of process, so long as it fits the business needs and staffing model of the company. What I am opposed to is the blind adherance to "industry standard best practices" simply because Acme Corporation does it that way or because "We've always done it that way."

In my gut, I am not convinced in the slightest that the Waterfall Method will work for our firm because we lack the staffing resources to make it work as it's written. We'd spend so much time in upfront information gathering (read: meetings), analysis, design, specification, writing, that we'd never actually get around to doing the work and getting the product delivered.

I've been with the firm for 3 years. It'll be 4 in August. I have always been the sole developer, and I have had to wear all the hats in the software process (developer, designer, DBA, architect, test engineer, tester, customer support rep, risk manager, technical writer, and on and on). I have repeatedly asked for another developer to help out. They have repeatedly refused despite the increasing workload, and still do so. So additional staffing isn't going to happen. I am very concerned that this process, if implemented, will bring all work to a grinding halt due to bureaucratic gridlock.

So, in closing: Are my fears justified or overblown? Is there a better process that I can recommend to them to replace the Waterfall Method? (There's no mention of iterative development in this plan, for instance.) Is there a reasonable chance that it will actually work? Should I just suck it up and give it a chance?

Thanks in advance,

Mike

This is a joke right? Some kind of test?

I think your fears are justified but maybe not for the reasons you think. The SOX auditor only has a big stick approach to be able to prove to the CEO that they should sign the annual report/financial statements. It is the safe way and an expensive way. In fact, what will drive your employer nuts is that software (which still will get done) will take longer and cost way more than desired.

The trick, of course, is to put in some tailored controls so that the CEO can have signing confidence. I don't have any resource of the tip of my head (at home on the weekend) but I am sure some folks have found out how to be SOX compliant in a more agile environment. Try a web search.

What a SOX auditor will want is proof that the software does what it supposed to do. Well, more precisely, that all reasonable measures were taken to make sure the software does what it is supposed to do. If you can show that in a way more suitable to your environment (sign off by customer on short development increments, automated regression testing, etc.) you may be able to convenience the auditor to OK your approach.

This is, sadly, most definitely not a joke. Every word of it is true. :(

I am sorry to hear that it is true! Do you think the business values getting ready for an IPO or more efficiently produced software more? If the former, than it may be a long road for you as they will listen to the consulting firm. If the latter, then you can probably make a case for how you can supply a "process" that give the right level of controls at a much lower process cost.

 Hi Mike,

Our company was recently acquired by an American company, and we are in the middle of adapting our SDLC(s) to be SOX compliant.

Of course you can use iterative or agile development and still be SOX compliant! It does sound rather as if your consultant thinks your company has some deep pockets! 

We've found that the things SOX auditors look for (ours are KPMG) have to do with assurances that business processes (especially (or solely, I'm no expert) financially-related) that might be affected by systems changes are documented and tested, that there is a particular person who is responsible for assuring the integrity of all aspects of business processes and controls, and that they are involved appropriately in decision making and authorisation on relevant projects. Also that test plans are assured to cover all financial controls and business processes, and that test results are archived for a determined period of time. Of course, there's more, and LOTS of detail. But basically, SOX is concerned with only some of your systems, and with only some of your development work on those systems. 

I would think that having a criteria you use to determine which systems and projects are 'SOX relevant' and worrying only about those might ease this distress. And if an agile approach needs to be modified in order to have the level of documentation, testing, trainign and assurances that SOX requires, well, then you could make those adjustments to the qualitfying projects' SDLC. 

Or am I over-simplifying?  

Thanks,

Debby  

All,

For what it's worth, I don't think the idea of a "standard SDLC" makes any sense in the first place. There's simply too much difference from one project to another--even though both projects are in the same company. I firmly believe that every organization needs to allow a spectrum of SDLCs. In a nutshell, the more agile lifecycles are very useful for what I like to call "research-oriented development" while the more plan-based lifecycles are useful for what I like to call "production-oriented development". Typically, a given software product would start it's *product* lifecycle on the research-oriented end of the spectrum (the key issue being, "Can we even do this at all?"). As the product itself matures, the successive project lifecycles move to the more plan-based end of the spectrum (the key issue evolves over time into, "We need to add this well-understood additional funtionality to version 9.7 of this well-known product").

Given that a single organization will typically have different products at different points of product maturity, then clearly they would need different SDLCs for each of the projects that are building the next versions of each of the projects.

What's needed here is actually a "meta-process". In other words, a process for building software processes. Of course, I wouldn't be mentioning this unless such an animal existed in the first place. It does. The top level description of the meta-process is, simply:

      1) Charter the project--this defines the goal(s) the project is intended to achieve (among other things)

     2a) Perform a risk assessment--this identifies the primary concerns the project should pay attention to (like unstable requirements for a research-oriented project)

     2b) Perform an asset assessment--this identifies the things this project has going in its favor (like stable, knowable requirements for a production-oriented project)

     3) Plan the project in a way that every planning decision, both what is done and how (formally) it is done, is consistent with the Charter, the risks, and the assets. The project that has the unstable requirements risk should naturally gravitate toward the agile SDLCs due to it's research nature while the mature product would naturally gravitate to toward the plan-based SDLCs.

There's a lot more detail on this "meta-process" if anyone is interested. For example, the meta-process is embedded in CxOne.

 Cheers,

 -- steve