Many IT companies downsized or restructured in the industry’s recent downturn. The resulting flattened infrastructure has affected software development, product quality, and customer support. In some cases, the deep cuts companies make to survive actually threaten their long-term survival by imperiling their ability to recover.

This high-level overview of development roles and their business value will illustrate the effect that downsizing has on the software development cycle and a company’s ability to survive, recover, and prosper.

IT roles
I’ve separated typical application development roles into several general positions. These roles are broken out into conceptual duties from a software project’s standpoint. I included purpose-driven groups, and not all positions are necessarily listed.

  • Project manager—Manages the planning, execution, and delivery of a project
  • Systems analyst—Evaluates the need for a project, performs solution due diligence, and facilitates integration of business rules and goals
  • Data architect—Discovers data relationships, creates data flow model, and designs business rule logic
  • Database architect (DBA)—Estimates data usage, designs database architecture, and deploys and maintains software database
  • Application architect—Reviews analysis and project information, designs software solution architecture, and incorporates change orders and feature requests in design
  • Lead/Senior developer—Creates core functionality and application foundation software and guides development efforts
  • Developer—Creates software and performs debugging and testing
  • Quality assurance (QA)—Performs testing of software and ensures solution meets with technical and business quality standards
  • Integrator—Creates distributions, builds upgrade scripts and packages, and installs and integrates completed application
  • Support engineer—Fields questions about the solution after deployment, seeks resolution, and interfaces with customer
  • Maintenance engineer—Ensures continued operation of software, fixes bugs, and performs upgrades

Now I’ll look at a scenario that involves eliminating some positions and shifting the roles of others.

Downsizing’s effects
To illustrate the business value these positions have on the software development life cycle, I’ll describe how eliminating roles affects a fictional company, Tralfaz Software. Tralfaz’s IT department produces custom software applications and maintains two “out-of-the-box” solutions that the team previously developed.

Round one—streamlining
Tralfaz’s first round of cuts takes a “streamlining” approach that is specifically focused on eliminating roles that are most useful at specific times during development and that can be incorporated elsewhere.

The data architect and application architect are the first to go, removing the middle tier of planning. At Tralfaz, the systems analyst is assigned to work with the DBA and lead developer to design a solution. The lead developer and systems analyst are able to delegate some of their work to developers and the project manager, but the DBA is stuck with the extra responsibilities.

At the other end of the cycle, the integrator and maintenance engineer are given the pink slip. They both knew it was coming because they’d been asked to document what they do and to train support engineers, system administrators, and developers to do it. The support department compensates by adding service tickets to their call-tracking system, and the developers use sneakernet to bridge bug fixes and integration issues to their bug-tracking and version-control software.

In the long term, Tralfaz’s custom development projects encounter more rework, logic errors, and database changes. Less efficient architecture designs lead to longer programming times. The support department is swamped and ill equipped to handle customers’ problems. Issue resolution begins to rely heavily upon developers, and integration tasks fall on lead developers.

Ultimately, while the process has been streamlined, the quality of support has declined, and development times have increased. Both development clients and businesses that have purchased the company’s products are less happy, and so are the developers and DBA.

Round two—deeper cuts and refocused efforts
In the second round, the cuts are deeper. Streamlining wasn’t as effective as anticipated, and investors aren’t happy with customer complaints. The company focuses its efforts on improving responsiveness to customer demands.

At the time, Tralfaz’s systems analyst had taken over production reporting chores and had a good rapport with the client, but the project manager had a better grasp on budgets and scheduling. The systems analyst is let go, and the project manager picks up some of her responsibilities. The rest of the analyst’s duties go to the lead developers, the DBA, and QA.

QA is cut to one person, who is instructed to work with support and developers for testing and reporting needs. The support and development departments are downsized, eliminating employees who are less productive or who have a smaller body of knowledge to transfer.

Tralfaz is really struggling. The DBA’s salary is large and, after much debate, he is also laid off. One of the lead developers is trained on the database.

At this point, the amount of work has really only decreased slightly, but workload has skyrocketed. Only four positions remain:

  • Project manager
  • Lead developer
  • Developer
  • Support

With the new structure, change orders and requests for new functionality are being denied. Database modifications and maintenance are handled haphazardly. Development times are even longer, and status updates aren’t readily available. Application platform issues are rampant, partially from code hacks put in place to handle issues stemming from lost knowledge. Human error in reporting systems increases drastically as everyone’s responsibilities increase. Projects start to lag, and scheduled maintenance, upgrades, and product releases are late or missed altogether.

Round three—the fight for survival
The previous cuts helped temporarily, but the industry is stuck in a downward spiral. Sensing that the end is near, Tralfaz creates an exit team. There may be a chance for survival, but the company must maintain a low cost center to qualify for opportunities. The quality of service has degraded, and Tralfaz is at maximum output. A couple of new client prospects exist, but the company realizes it must staff to match current demand, not a future that Tralfaz may have.

The support team and its services are eliminated altogether. The remaining QA engineer is changed to an administrative position, handling reporting and customer requests rather than developer support. The project manager is laid off, handing off responsibilities to account executives and the remaining lead developer. The development staff is cut again, leaving just enough people to meet current development demand.

Once these layoffs are completed, Tralfaz is in stasis mode. Role consolidation may have reduced Tralfaz’s expenses, but it cost the company clients and led to a decreased achievable level of service. Production is minimal. Products are being terminated, and the team can’t live up to the Service Level Agreements required by larger clients. Custom development work by programmers serves as a last-ditch effort to keep the company afloat, but new solutions are buggy and expensive. The company is reduced from an application development firm to a run-of-the-mill development shop. Ironically, the deep cuts Tralfaz made to survive have made it unable to develop the products it needs to attract and retain clients.

The lesson learned
Over time, companies learn what they did wrong. In the IT world, a few survivors are attempting to repair the damage.

The first lesson is the need for an architect. Companies that laid off experienced DBAs in favor of cheaper, less experienced talent learned why architects command hefty salaries. Job listings remain scarce, but many are for multitalented architects and DBAs.

The job market for support and integration engineers has picked up as well, though not as much as the demand for DBAs. Many companies realize that technical client relationships require a talented staff.

There’s also been a rising demand for project managers and systems analysts. Companies that thought nontechnical employees would be able to interface directly with developers learned the true value of a translator.

The critical IT roles, therefore, are:

  • Development—the core of producing software applications.
  • Architecture—the ability to start new endeavors and manage data.
  • Support—a technical bridge between the client and the developers.
  • Management—an infrastructure and process-driven framework in which the solution is achieved.

All the roles I listed at the beginning of this article fall into one of these categories. Completely eliminating any one of these four pillars will begin to erode the software development life cycle—and take your company with it.

Maintain knowledge centers
If you must downsize, protect core roles by any means possible. If you lose any one of the development, architecture, support, or management knowledge centers, you may find your company in the same situation as Tralfaz, without hope of recovery.

How have you planned for recovery?

Has your company faced a struggle similar to the situation described in this article? What measures have you taken to ensure that your IT department will be able to bounce back?