Quality Assurance Governance is all about being organized and prepared to do the job right. It is about collecting best practices in development and sharing that collection with the rest of the organization to make sure quality is the focus of a continuing improvement of the way we work. Although there can be an element of Internal Audit to ensure compliance with the intent of the SDLC Methodology the focus should be on enabling developers to do the best job they are capable of. Any audit aspects can be useful to identify what weaknesses exist and what further learning is required, and you can use that feedback to develop new opportunities for growth. The opportunity for personal growth should be open to all development staff in the interest of building quality into systems by design. A large part of QA Governance is therefore the carefull management of a process to introduce a quality consciousness that gradually builds confidence in the development methodology until it becomes ingrained.

Our general approach to SDLC Methodology is based on the belief that people like to have a recommended way of doing things because it takes the stress out of determining what to do next. An official methodology ensures that all projects will pursue at least a minimum level of quality, but if you can establish a quality culture built around the SDLC best practices you may be able to reach exceptional levels of quality performance. This does not have to be complicated at all, and at first you can start with a basic methodology that you keep improving as new best practices needs are identified. Best of all, with this approach the SDLC becomes uniquely applicable to your work environment. For a quality culture to take hold it will be necessary to foster the right attitude towards best practices and to not succumb to cutting corners on every project in order to save costs. There is a need to send a consistent message that quality should not be compromised and that shortcuts are considered only if there is a real emergency that cannot wait for a normal development life cycle to complete.

PM4HIRE.COM can be engaged to introduce a starter SDLC methodology and to work with your team(s) to evolve the methodology so that it is most meaningful in the context of the work that these teams perform. It is important that all the implied or express Governance rules be adapted to reflect your organization. While there are only so many basic ways to implement I.T. projects each company has unique rules for managing projects and for communicating into and out of a project. For that reason you cannot expect a "one size fits all" SDLC process that will take care of all your development needs, and even within a larger organization there may be different communications strata to take into consideration, or to establish a unique Governance matrix for who are to sign-off on a project deliverables, which directly impact on how the SDLC is rolled out in the first place, let alone how it will be received by the development team(s). It is absolutely essential that there is top-down buy-in for the formal methodology because during the initial learning curve while adopting a new methodology there can be increased costs and/or duration to get the job done right. That is an investment the company should be willing to commit to if you want to get to the point that quality results start to produce real benefits.

Delivering a customized SDLC is not a small task, even for a small development organization, but it has long been recognized that standards are the only way to control the costs of most projects. One of the claims often used by offshore development houses is that their practices are at a CMM-5 level of quality, but all that really means is that they have a highly customized methodology that is rigorously adhered to each time a new project is undertaken. Standards and reusability are better ways to save money than to outsource development work to offshore vendors, in particular because it will also benefit the ongoing maintenance of those systems that are produced in a standard fashion. It does not pay off immediately, as the objective is to incorporate lessons learned from all completed projects as improvements to the SDLC until your internal processes are so standard that you too can claim to be CMM-5 level compatible, at which point projects should run super-efficiently. Through standardization can you aim for the reusability of code that will produce the biggest cost reductions.

Without development standards everyone chases their tails...

Imagine for a moment that all development was done differently each time different teams start a project, and that nobody bothered to tell the next developer what approach was used so that each maintenance opportunity resulted in additional non-standard work effort. A large part of the work effort would be wasted on trying to sort out how the work would be done, never mind what work is required. This may be great exercise, but it is not a productive use of technical talent.

PM4HIRE.COM has experience with introducing proper SDLC methodology in order to dramatically improve the workflow efficiency in I.T. development. For example, the fact that people know what is expected of them and in what sequence the work needs to be performed makes it easier to plan the work in advance and to get to end of job in the shortest time possible. Contrast that with people trying to figure out what to do next (and getting it wrong from time to time), and you can imagine the cost savings inherent in following a structured process. With standard processes you can provide much better estimates of what it will cost to implement different solutions, and people will not be as inclined to haggle in order to reduce costs when you know that the work still has to be done and that there will be cost overruns. Worst of all, since the job is not done right you do not get the quality benefits you want.

The first step is to produce an end-to-end methodology that covers all aspects of the development life cycle, including subsequent product maintenance and including procurement where necessary. This is the big picture that explains how all the workflows combine into an overall effort to produce the right software that meets all the real business requirements. This ensures the forest is not hidden for the trees, which may happen if you focus only on "how to" information. In particular the need to sell the methodology to the decision makers calls for the definition of a "big picture" overview and the justification of the process before the details are ironed out. There is a need to be realistic about how much effort it takes to get everyone on board with the initiative.

The second step is to detail the work effort that is involved, so that there is a complete reference guide for each workflow in the SDLC Methodology. We have developed many "how to" guides that explain the workflows and the expectations of what is to be delivered that can be customized to the specific needs of your company. We are well aware that once size does not fit all, as larger companies have more complex approvals processes for example. The appropriate reference guides should be available on-demand, so that people who are faced with the need to do a particular job that they are not familiar with can immediately get the information they need. One thing to keep in mind is that not everyone that reads the same document perceives the same information as everyone else, but at least the basic workflow effort should be properly interpreted and executed.

The third step is the most intensive, to lead people through the methodology by teaching them what you want them to do in each workflow. We have heard the argument that people are professionals that do not need extra training, but we don't buy into that. PM4HIRE.COM has instead focused on developing the appropriate training programs that people need exactly because they do not automatically grasp the intent of the SDLC Methodology. Because they are repeatedly told they should know what to do because they are professionals, developers do the best they can. Individually they may in fact produce brilliant results, but that is meaningless if they cannot use each other's code, or if they write code for ill-conceived or incomplete requirements, or for many other reasons. The QA Governance focus is on consistency and similarity and interchangeability of project deliverables to the point that different stages of a development project might be completed by different people and yet you would not see that difference as there is an overall consistency in everything that has been produced.

A lack of standards is a sure way to sink projects...

What projects without a proper SDLC methodology have in common is that more energy is wasted trying to determine what to do next than to get actual work done. That includes work to be redone because the timing of the initial effort was all off. A standard approach to solving problems in an organized fashion will consistently get you the results you want without the risk of sinking.

PM4HIRE.COM has collected a library of best practices for years, and the remarkable fact is that even the older guidelines could have saved many projects we have seen getting into trouble. What we have done over the years is to keep the best ideas as new approaches are floated, and to update the best practices for use with modern technologies. This is the essence of QA Governance, to keep the processes alive and relevant in order to encourage the development staff to adhere to these processes because they know that success follows. Occasionally we see some radical changes, to accommodate new technologies, but eventually things have to settle down to a level where people are comfortable with the way these best practices can be most effectively employed.

Sometimes industry best practices are not compatible with the culture of an organization so that you are better off with a more pragmatic approach. Prototyping is an example where many good intentions have backfired when clients perceived the model as a finished product and aimed to put an unfit product into production, or showed much impatience with the time it takes to go from a prototype to a production ready version. The approach may be excellent for some organizations but it would spell disaster for other organizations. It is important that each approach be reviewed in terms of how you expect the organization to accept the results in practice. This is not being critical, this is being realistic about what processes will work and what processes will not work. Often it can be best to introduce a lot of flexibility into how the methodology will be enforced by the QA Governance team.

SDLC Methodology must guide all development projects...

The point of a guided tour is that you will visit all the sights worth seeing, and an SDLC Methodology is not much different in that respect. Let's say that it takes the "Oops!" factor out of a project so that you are better prepared to complete the work in an organized fashion. You may not go wild over all the spots you visit but at least you have had the chance to take a look and to decide for yourself if you want to spend some time looking at different aspects pointed out by your tour guide. Rules for following the SDLC Methodology should be looked at in the same way.

PM4HIRE.COM believes that the role of the SDLC Methodology is not to force detailed work activities down everyone's throat but rather to show all the work activities that should be considered in the project. Depending on the size of the project you would scale the level of effort accordingly and work to the spirit of the methodology rather than to see it as a rules book. There tends to be a more-or-less fixed overhead cost associated with the process itself, not in the least because of an emphasis on adequate documentation, that might be too much overhead on a smaller project. One way to look at the level of enforcement of any methodology is to consider the risk impact of not strictly enforcing the complete methodology on a project. Any mission-critical project, no matter how small, should follow methodology, but any ad-hoc work effort may as easily be governed by general guidelines instead.

Like water, people will follow the path of least resistance. If you offer people the alternative of bypassing the methodology then that option will become a popular choice. It is only after the benefits from using a formal methodology become at least apparent that you can expect to see more buy-in from developers. What that means is that initially you may have to set rules that you can later on relax, otherwise the general tendency will be to skirt around the methodology. This is where the initial audit role of QA Governance comes into play in order to establish the best practices initially until the rules can be relaxed once people are better able to judge which projects might be done without following the strict methodology, and you may very well continue that level of QA control to make sure the relaxation of rules is not going to regress development into a free-for-all that produces results of questionable quality. There should never be a short-cut to chaos.

You have the responsibility to make sure that the methodology is completely relevant to the way your company does business, so that following the rules ensures that the desired results will be obtained. QA Governance is also involved in reviewing the successes and failures of projects so that lessons learned can be applied to the methodology by improving the underlying processes. People should have input into what works and what does not work, to make sure the methodology stays alive and that it does not lose its relevance. People find ways to work around processes that they think are irrelevant. Before you judge the infractions, listen to the reasons why they think that there are better approaches to achieve superior results. I.T. development is a continuous learning opportunity as new challenges are addressed in project after project. It would be presumptuous to believe that there would not be good contributions from people who are actually doing the job according to the methodology.

SDLC Methodology should cover all the tools you need...

Like using a Swiss Army knife you will use some parts of the SDLC Methodology more than other parts, but you always have a useful tool for whatever job comes up on short notice. Being prepared can relieve a lot of stress.

PM4HIRE.COM uses the SDLC Methodology as a way to scope projects as early as possible, and we use the performance history of similar projects to help us produce work estimates for new projects. That is just one small example of the kind of tools you can evolve from a consistent way of doing things. The fact that you will have documentation templates for all standard deliverables, plus step-by-step guides on how to complete each workflow, should make life easier for all developers. Tasks that will be done over and over again can be (semi-)automated, or the right software can be acquired to help in the execution of standard tasks. Consistency simply leads to process improvements by providing an opportunity for streamlining the work effort, whereas treating every project as a completely unique experience makes it difficult to gear up. Having said that, we know that projects are defined as unique efforts of a limited duration to produce a carefully defined objective. By definition then, each project will have to adapt some aspects of the general methodology to accommodate what is special about that project.

If the SDLC Methodology is a complete and detailed roadmap for developing software, then the unique aspects are only small detours that will not throw anyone off course on specific projects. If you only have vague notions of what approach you should take for an average project then the opportunity for getting lost is that much greater. If you simply publish a methodology without providing the proper QA Governance to guide the development teams into using that methodology it will simply sit on the shelf gathering dust. You will be building a legacy of software that will prove to be difficult to maintain so that the longer you wait the harder it will be to introduce appropriate quality practices that will ultimately determine the success of your development efforts.