Discovering and Being Aware of Software Engineering Capabilities & Risks
Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.
I've frequently worked with program and project teams that have ad hoc methods of software engineering. These software engineering methods introduce risks that should be identified and managed throughout a program and project's lifetime. Unawareness of these risks introduces a high probability of avoidable issues occurring.
As a Program Manager, are your project teams applying robust software engineering practices? What software engineering risks are present?
Ad hoc software engineering practices can result in lost source software and scripts, inability to find the latest technical documentation, untracked production changes that introduce instability or break functionality, cybersecurity gaps that pose risks to the business, and more.
Program Managers need to uncover potential software engineering risks and guide project managers in managing those risks.
Here's one experience I've had (and there are many others!):
The launch of project XYZZY, one of the projects on the program I was leading, went well.
A few months later the technical lead unexpectedly departed. Went home one day and never returned. This lead's design, software source code and other assets were somewhere but that project team couldn't locate them. In our case, the lead's departure introduced a many months delay while re-creation of the lost assets proceeded. Unfortunately, this was a costly recovery.
While a cause of this situation was the company's laissez-faire approach to project management and software engineering methods (leading to a proliferation of informal methods), this risk is something both the project manager and program manager (me) should have understood at the outset.
While program managers tend to spend most of their energies on schedules, budgets, issues and the like, there is another area deserving of attention: software engineering practices. This article is about understanding software engineering risks present on your program and the guidance and leadership you can provide to project managers and technical leads in understanding and managing these risks.
Software Engineering Skills and Experience are in Short Supply
It feels like it is getting harder and harder to ensure sufficient technical depth of knowledge and experience on program teams.
The proliferation of platforms, 3rd party COTS solutions, vendor developed systems that have been turned over to you, and advances in underlying technologies has made it more difficult to ensure a sufficient technical knowledge base for many projects.
An important responsibility of the program team is the management of the solution's technology - having a forward-looking view, developing expertise in the technology, managing technical debt and eliminating obsolete technology. Along with this are the software engineering methods and enabling tools used by the team - let's focus on these.
When launching a program that will deliver a valuable business solution, here's what I've encountered in organizations that don't have rigorous software engineering practices in common usage:
- Software engineering behaviors that introduce quality, operational or schedule risk
- Code residing solely in an individual's file system, not on a company version control system (e.g., GitHub). Informally managed software can become a lost asset when a team member departs. As well, when using individual storage, version control is often a problem.
- Individuals creating code or modifying code with no involvement of others (e.g., absence of pair programming or peer reviews), thus increasing quality and stability risks.
- Manually configuring production platforms on the fly, with a lack of change and version control. I've had to suppress my cringing when learning of untracked changes made to production platforms - this increases stability risks and surely increases maintenance costs.
- Manually deploying into production, foregoing the more appropriate use of DevOps capabilities. Manual actions increase the risk of unintended human error.
- Technology expertise is hard to find
- Shared services, like cyber security, are frequently overloaded with work and cannot devote timely attention to our program's projects.
- Updates to legacy systems are needed for the program, but the expertise in those systems departed the company years ago.
- Newer technologies have exciting capabilities, but experienced talent is in short supply.
- Technical Debt is a costly obstacle
- Older COTS systems are beyond end-of-life and must be replaced in order to provide the capabilities we need. Ditto for older in-house developed systems.
Approaches for achieving program delivery
I've experienced each of these issues at least once, and perhaps you have as well. I've taken these experiences and have incorporated more thorough discovery and planning into program inception activities and ongoing risk management.
Here are some of example tactical steps I've taken in guiding project managers:
- Software Version Control. Transitioning a project to make use of a shared space for assets is a painful but necessary step. Implement the company's version control and developer collaboration tool (e.g., GitHub). Establish working norms that require all production changes to be under version control.
- Collaboration. Make effective use of high capability collaboration tools (MS-Teams/SharePoint or Google WorkSpace) that provide sharing capabilities, document version control and direct messaging. Establish norms that put an end to emailing documents back and forth.
- Addressing technical debt. This one is hard with the ever-present focus on delivery of new capabilities. The first action, taken during planning, is to reserve a small amount of capacity that is allocated to reducing technical debt (for Scrum teams, this happens at the team level during Sprint planning). The second action is to give visibility to any technical debt being introduced by the program and identifying alternatives or mitigation actions.
- Contractors - Legacy Systems. If we don't have the expertise (for older systems) in-house, we bring that expertise into the program as needed. We allow for the expected costs of onboarding and technical oversight.
- Contractors - New Technology. Sometimes the shiny new item is just what we need now and for the long term. To accelerate our use of a newer technology we assign in-house technology responsibilities and supplement temporarily with external contractor expertise.
Thinking strategically
Program managers are appropriately focused on driving to program success.
Let's think a bit more broadly about your role in the organization.
With your extensive program manager expertise and your position of significant authority and influence, create openings to have a strategic impact in driving organizational improvements to software engineering practices.
Identify opportunities to impact software engineering areas where there are needs in your organization. You'll read the items in this list (below) and will likely react with "We've known for years that these are problems." See yourself as the leader you are - go beyond that observation and create solutions:
- Software Engineering Practices. Ensure your project teams are applying current software engineer methods for DevOps, peer review, TDD, automated testing and much more. Ad hoc software development and antiquated software engineering methods cannot serve the organization adequately.
- Technical skills for the future. Build a broader and deeper base of expertise in relevant or emerging technologies. Ensure the organization's consistent support of relevant continuing professional training and education. I'll go out on a limb with this specific suggestion: in 2024 every technologist should have a minimum of 40 hours training in some aspects of Artificial Intelligence. Data scientists and database specialists should probably have double that amount.
- Accountability for managing technical debt. Everyone knows that technical debt is an ongoing issue, and teams frequently complain that the urgency of new products and capabilities is preventing any reduction of this debt. Solve that problem! Any additions to technical debt must be visible and understood. Any decisions to continually postpone the reduction of technical debt must be visible and understood. System, application, platform, and agile teams must have mechanisms for successfully managing technical debt. From experience, I can tell you that lack of progress over a period of years in these areas will almost surely impact the cost and schedules of new technology programs.
- Sunset obsolete applications and platforms. These probably are a cybersecurity risk anyway. Don't wait for a major initiative as the impetus for cleaning house. This should be a continuous activity.
These strategic topics are probably not directly related to your responsibilities to lead a program. I do understand that.
However, your position as a leader in the organization creates a legitimacy for you to help address the organization's software engineering maturity and the quality of the technology systems/platforms. I'm familiar with the push back, "We understand the issues but don't have the capacity to take any corrective action." Unless someone is advocating for action in these areas, the status quo will prevail. Carpe diem!
What does this mean for a Program Manager?
Throughout the program, give ample consideration to the state of software engineering practices in the organization and the depth of expertise within the project teams. Avoid assumptions (e.g., "everyone uses a version control system for software" or "quality assurance activities are good") that can introduce issues during execution - some due diligence at inception can avoid a serious issue later. At the completion of the program, strive to leave the project teams stronger that at the start.