Standards are basically officially sanctioned statements of what must be done and Frameworks are basically officially sanctioned statements of when and how things must be done. Throughout the rest of this article I will be using the term “standards” to encompass both Standards and Frameworks since I will not be focusing on the details of either. That being said, both generally seem to mandate massive amounts of overhead, so much so that unless one is being paid to follow them, it seems to be impossible for the Little Guy (a company or team that actually qualifies as a small business) to follow them. Why then should the Little Guy even try to comply? What's in it for him?

Well, first off everyone should be knowledgeable about their area of expertise. In other words, if you work in the CM niche, then you should be aware of what standards exist and basically what they cover that concerns CM. Similarly, if you are a Development Manager, or are fulfilling that role, then you should similarly be aware of the standards that concern the development process. But, you say, I am not bound by any standards so why should I bother? The simplest and most pragmatic answer is so that you will be perceived as someone who knows their job – in other words, it affects your personal reputation. The second reason is that the standards came about because of a need to reduce confusion while maximizing productivity (where productivity means delivering a quality product on time and within budget). And if that is not enough, standards are generally considered to contain “the wisdom of the experts.”

That does not necessarily mean that you should follow the standards slavishly, for that way lies bankruptcy. Standards are written to govern the worst case scenarios. This means that they do not assume co-location or ease of communications. They assume that the people working on a product today will not be the same ones working on it a few weeks, months or years later. They assume that the resulting product will need to interface with other products and that how those interfaces are specified need to be spelled out to avoid confusion. So, what should you get out of standards? You should get a feeling for when things need to happen, what practices are (or were at the time the standards were written) at least reasonable if not “best” and what documentation needs to be produced to go along with the product.

All standards are concerned with internal project governance, accountability, etc. Most of this can be refined to “just enough” documentation at just the right times to keep things on track and to spot problems before it is too late to do anything about them. Things like project schedules, deadlines and when and under what conditions you get paid. You also get a feel for the amount of time you should spend in any particular phase of the SDLC, not in term of calendar but in percentages of the project duration. You also get a feel for some design/architecture guidelines that can help make the product inherently better over its life.

Standards are also concerned with project externals such as subcontractor management, interface specifications and user documentation. These you will need to do and the standards give you a good feel for both expected level of content and appearance. If your product will be integrated with others, then you want to be able to read their interface specifications without surprises as others want to be able to read yours. This is a case where using common standards helps avoid confusion and possibly the rejection of your product. How often have you bought something and had trouble understanding how to use it? Was the problem with the product or with the documentation?

In a way, the early Agile adopters decided to gut the standards since they felt, with some justification, had a level of overhead was killing projects more that helping. What they ended up doing is the same thing the Little Guy has always had to do, pick and choose which parts to use and which to ignore. I can just here readers saying , “So... how do I know what to pick?” Let me give you an example from when I used to run a consulting company during the '80s and '90s.

During the '80s I primarily did real-time and embedded systems development, including device drivers and real-time executives. There were very few Version Control or Defect Tracking tools available that were not fairly expensive for a small company, but I knew from past experience that we had to have them. I typically was either a part of a small team, or headed up a small team, where personalities were just as important as skills. We ended up generating flow charts to describe our development process and included such items as references to entry/exit criteria at critical junctures. We designed the code to be modular in nature with minimum cross-function interfaces (this has since become known as architecting the system). We kept track of our progress on big charts that represented the modular layout of the system with special colors to percent complete and indicate changes to interface that could impact others. Among the other internal documentation generated were crib sheets for the commands necessary to check code in/out and to enter defects, issues and resolutions into our Defect Tracking system – first a Multiplan spreadsheet and later a dBase database.

What we basically had was a lean visual method of displaying the codebase structure, its interfaces and our progress during its development. Other than a brief description of the product, including its long term projected enhancements (so we did not accidentally prevent their later addition), that constituted our internal documentation. As far as external documentation was concerned, we produced a User Guide and a User Reference Manual. The first described how to install and use the product and the other provided details of any interfaces, including the format of any data files. We called our SDLC Iterative Development and we used short 1-4 week cycles, depending on the function. The first code we developed were the high-level functional modules with stubbed interfaces that matched our original design. From that point on, we developed functions as they were needed and were able to demonstrate the evolution of the working system early on to the customer and get feedback and scope change requests )meaning more money!) throughout the product development.

Sounds remarkably Agile, but without the metrics, charts and daily meetings. We successfully used this model for almost 20 years and it scaled up reasonably well, so long as the functional teams were kept very small and intact. When we had to do contracts that required DOD or IEEE standards compliance, we did so, but we were able to boiler plate most of it and reuse it from project to project. All we had to do was to change it to match the differences from the template and add appendices as necessary. Where possible, we used the system itself to generate the additional documentation for us.

So, the Little Guy does need to know the standards and does need to follow a set of standards even if they are internal ones and not the published ones. Customers and prime contractors generally want to see something formal that they can use as legal or quasi-legal documents as a part of the contract, and having these ready to hand makes one seem more professional and competent. Just don't go overboard.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment