 | Level: Introductory Danielle Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
Nelson Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
16 May 2006 Development -- whether internal or commercial -- is a cornerstone of IT. But if performed in an uncontrolled manner, the development process can result in a high-failure rate and become the bane of a project manager's existence. To reduce the risk of failure, organizations must move to a governance model for IT development -- a model that ensures that projects are controlled from start to finish and are always on track.
Introduction: Good development gone wrong
Software development projects are notorious for cost overruns, missed deadlines, and constantly changing scopes. Why
is that? Why is it that when you set out to develop a product -- be it an operating system, a device driver, an
internal application, or even just a Web page -- you can't seem to get programmers to deliver on time, on budget,
and with the level of quality that can make you shine?
Of course, not all development projects run into these issues, so what makes them different? What makes them
succeed? In many cases, these projects achieve their goals because of proper IT governance. Governance helps you
lead and especially control the progress of development projects and keep them on track. Governance doesn't
have to be onerous, nor is it monolithic. While there is no "magic" solution to proper governance of development
projects, you can implement a key set of processes that will help alleviate the most common issues.
Define your view of governance
Governance doesn't mean the same thing to all people. First, governance doesn't mean rigidity or, if it does,
it's only as it applies to compliance to a process. Too many organizations use spur of the moment processes for development. If they use an internal process, they either stick to it too rigidly or not enough. Too much, meaning
everyone sticks to the letter of the process, often concentrating on the wrong aspects and failing to focus on
key factors that make the process work. Too little, and there's no direction to make sure that the right
aspects of the process are covered at the right time.
No, effective governance means putting the right process in place and, if you need to, putting in the right tools to
support this process. But, keep in mind that what's important here is the process itself. It must focus on the
right activities at the right time, and rely on one main key factor: communication among all interested
parties. Too many projects fail because no communication exists among all the interested parties.
The ideal development process
So, what makes up the ideal development process? It should be in the form of a life cycle and include, at
the very least, the following phases:
- Project definition
- Preparation
- Development
- Testing
- Code maturation
- Deployment
- Support
- Retirement
Project definition
This stage is probably the most important in the process, because it determines how the project will evolve.
The key activities of this phase are the proper definition of the requirements as well as the determination of the
project scope and budget. Interview skills are important here, as is the formal capture and reiteration of the
requirements to stakeholders.
Keep the overall scope of a project as small as possible: Taking on massive development undertakings only
leads to failure, because there are too many moving parts. Keep it simple, and you're much more likely to
succeed. With the advent of service-oriented architectures (SOAs) and their reusable components, keeping
project scopes smaller is much easier today that in the past.
Preparation
After you've defined all the key elements that make up the project, you can move to the preparation of the
project. In this phase, you refine budgets, develop the teams that will be involved in the project, and assign
their responsibilities. Ensure that communication channels are established among all team members.
Too many organizations make the mistake of involving only development team members at this stage, which
leads to products that are ill-prepared for delivery to production environments and that will lack support, training,
and any other nondevelopment mechanism required for their operation. Because several teams will be required
to ensure high quality for the product, each one should have a representative in place at this time. Communication
mechanisms should also include frequent feedback to stakeholders to ensure they are completely aware of both
unforeseen challenges and successes as development proceeds.
Development
In this phase, you actually code the product. Today, many organizations are using geographically dispersed
development teams, which can lead to scope creep unless, once again, proper communication channels are in
place. The best way to approach this distributed development model is to ensure that your development tools
support proper source management, providing both a single repository for the code you're working on and
audit trails for who is working on what. In addition, you might include frequent code builds with checkpoints that
help indicate overall project progress.
Testing
Testing begins after you start releasing core code components. Several levels of testing are required: unit,
functional, integration, staging, pilot, and finally, production. Testing involves different team members from the
developers themselves to end users who will provide acceptance for the final product.
One of the best ways to facilitate this process is to ensure that a strong dialog among technical and development
teams. Many projects fail at this level, because developers discover that they need to code to environment
specifications that were unknown to them. One excellent example is the difference between unit testing and
integration testing. In unit tests, developers often test on their own computers, where they act as users with
very high privileges and where few standards are implemented. After they get to the integration level, the code
no longer works, because this level begins to provide the same standards found in production. It is therefore
vital that a complete list of environmental specifications be provided to developers at a very early stage. Ideally,
the same standards should be used at all levels of testing and development, ensuring that won't be any
surprises as the product progresses through various testing cycles. The best way to achieve this is to use the
same build process for development, production workstations, and servers.
Code maturation
Maturation is the integration of all aspects of the new product's functions into a single coherent
component. If proper communication is implemented throughout the testing cycle, this phase becomes mostly
perfunctory and focuses on minor corrections to documentation, installation instructions, support materials, and
training tools. It also focuses on ensuring that the code is stable and can provide the level of reliability expected
from the product. Versioning is important at this phase to ensure that all team members know which level of the
product they should be working with.
Deployment
If a proper graduation process was used in the two previous phases, deployment is simply a matter of
reiterating the same process, but on a grander scale. Feedback on all the deployment mechanisms should be
provided through the pilot project. You can then make adjustments to ensure that the production deployment
goes as smoothly as possible.
Support
Now that the product is in production, it enters its support and maintenance phase. Depending on the business
value derived from the product, this phase can last much longer than any other. It involves the delivery of patches
as unforeseen glitches are discovered, and additional requirements are defined. These requirements often arise from the
use of the product: Users now discover that their needs have been changed because the product now
supports processes that were not available to them before.
Retirement
After the business process, the product support changes (as is typically the case with today's fast
pace of business), it becomes slated for retirement or replacement. This can take the form of the preparation
and deployment of a completely different product or simply an upgrade to the existing version. In some cases,
the whole process becomes obsolete, and the product must be completely retired from production. If the project's
scope is properly defined in the beginning, this retirement will be planned and ordered.
This process is illustrated in Figure 1. For most development teams, this process may come as a surprise, as
they tend to think that development ends with delivery to production. However, each product has a life cycle
that doesn't end until retirement from production. A holistic view of this life cycle serves to add value and quality
to products as they are prepared and delivered.
Figure 1. The development product life cycle
Look to your peers
Governance is applied by ensuring compliance to this process for each development project. The Enterprise
Information Technology Architect (EITA) is the ideal role for ensuring that compliance is met in all such projects.
In fact, this should be one of the EITA's major responsibilities, along with the overview of communication processes
among all interested team members and the documentation of all required architectures.
Another way to ensure that code is properly prepared and designed to meet expectations is to perform regular
peer reviews throughout the entire life cycle. Peer reviews can occur at each level of the process and should include
not only fellow developers but users, stakeholders, technical and support staff, as well as the EITA. This process can
only help ensure the overall quality of the product, because it helps find defects early in the development process,
allowing the development team to provide immediate corrections. Perform peer reviews often, and make sure
that your development process provides the proper mechanisms for feedback to appropriate team members.
Experience is the sum of your mistakes!
As you know, there's no magic solution to cost overruns, scope creep, or other development project failures, but
process -- especially process that focuses on the right project factors -- can greatly alleviate these issues. You can
see this in most projects.
Recently, our team was working on the delivery of a new application and its testing in a series of different environments
prior to its release into production. As testing progressed, we discovered a number of issues with the operation of the
application. One of the team members -- the official scribe for the team -- put together an e-mail message with all
the remediation steps we performed to get the application working properly. The team member sent the message
to the entire team, which included the developers who were in charge of preparing the next release. Two weeks went
by before the next reinstallation was to occur. Once again, we ran into the same operational issues, and we had to
dig to discover what was wrong.
The EITA suggested that we pull up the e-mail message that was sent after the last installation, and lo and behold,
each resolution was documented in the message, but it turned out that the developer in charge of making these
modifications had put the message away and ignored it because it only came from the scribe and not a more official
team member. In short, an installation meeting that should have taken 10 minutes took more than five hours and
involved several team members. The problem wasn't actually resolved until the EITA recalled that many of the
issues we were seeing were already documented.
Each project you complete adds knowledge and expertise that helps you gain a better understanding of the overall
process. Experience is the sum of your mistakes! Learn to rely on your teammates -- all of them. Governance
is nothing more than making sure you use the proper course of action in your development projects and that you follow
through on them. Often, it is only a matter of adjusting expectations -- not only those of your stakeholders but also
of your developers and every other team member.
Resources Learn
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Discuss
About the authors
| 
| | Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network,
computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help
desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a
Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at
architectures@reso-net.com. |
Rate this page
| |
