Software solutions based on customized packages or custom made applications clog the Corporate IT Landscape. Developing stable IT solutions that can shift alongside business requirements is top priority for today’s IT managers.
In many organizations, the approach to software development stands on Project Management (PM) practices. Whether traditional or more agile, those PM patterns are supported by a Project Management Office. But “delivering projects on time, within budget and according to scope” is not enough.
Continuously failing to (1) deliver solid SW aligned with best practices, (2) low maintainability (3) and intricate deployment procedures; will eventually spawn out of control.
Most of these problems are uncharted territory for the PMO. I’ve witness projects that, although huge successes from the PM point of view were total rubbish, considering the developed SW quality, reuse potential or complex operating procedures. The subsequent projects, set on top of the same SW were a nightmare, as you might have guessed.
A PMO can make a difference aligning project and portfolio under standard processes, controlling risk exposure and dependencies between projects, not to mention financial management. But it’s time to setup an enterprise wide Application Lifecycle Management (ALM) Office that can work alongside the PMO assuring a proper technical rollout.
Continuously failing to (1) deliver solid SW aligned with best practices, (2) low maintainability (3) and intricate deployment procedures; will eventually spawn out of control.
Most of these problems are uncharted territory for the PMO. I’ve witness projects that, although huge successes from the PM point of view were total rubbish, considering the developed SW quality, reuse potential or complex operating procedures. The subsequent projects, set on top of the same SW were a nightmare, as you might have guessed.
A PMO can make a difference aligning project and portfolio under standard processes, controlling risk exposure and dependencies between projects, not to mention financial management. But it’s time to setup an enterprise wide Application Lifecycle Management (ALM) Office that can work alongside the PMO assuring a proper technical rollout.
While the PMO handles the Project Portfolio, an ALM office should handle the application portfolio organized by technology, tailoring each application into defined standard processes:
Version Control: Instead of each team setting a Version Control System under the desk, centralize and manage a shared server.
Requirement Management and Tractability: There should be a standard process/tool to register and classify requirements that will be shared for analysis, development, testing and operation.
Standard Technical Documentation and Peer Reviews: Although underrated, every development effort should start with the technical outline. Remember that the major flaws in SW are conceptual, a sign that the development started too early.
Code/APIs/Logging compliance requirements: Implement Static Code Analysis, track technical debt, and capitalize the reuse potential. Centralized Logs for application clusters is not new, try to implement it.
Test Coverage and Issue Tracking: Unit Tests? Test Automation? How healthy is the produced code?
Deployment/Release Management Requirements: Continuous Integration and short releases have become a standard. Can all the applications be attached into a Continuous Integration Server and be deployed into a container?
(Not exhaustive)
PM Audits are a disseminated practice, to assure whether standard project management processes are being followed and Project Status.
Have you ever been on a Technical Review or Audit? Perhaps, but much less frequently, I’m sure.
By setting the standards, the ALM office has the obligation to push the organization into a continuous delivery model. Typically the problems stated above are handled in an ad hoc fashion by application experts, without being integrated into an overall strategy required by Corporate IT. Redefining a coherent and streamlined process for new and legacy applications, will set the ground for swift and consistent SW development.
(The content is not connected to my employer or to any software vendor. It only expresses my thoughts on various subject matters related to my field of work.)
Version Control: Instead of each team setting a Version Control System under the desk, centralize and manage a shared server.
Requirement Management and Tractability: There should be a standard process/tool to register and classify requirements that will be shared for analysis, development, testing and operation.
Standard Technical Documentation and Peer Reviews: Although underrated, every development effort should start with the technical outline. Remember that the major flaws in SW are conceptual, a sign that the development started too early.
Code/APIs/Logging compliance requirements: Implement Static Code Analysis, track technical debt, and capitalize the reuse potential. Centralized Logs for application clusters is not new, try to implement it.
Test Coverage and Issue Tracking: Unit Tests? Test Automation? How healthy is the produced code?
Deployment/Release Management Requirements: Continuous Integration and short releases have become a standard. Can all the applications be attached into a Continuous Integration Server and be deployed into a container?
(Not exhaustive)
PM Audits are a disseminated practice, to assure whether standard project management processes are being followed and Project Status.
Have you ever been on a Technical Review or Audit? Perhaps, but much less frequently, I’m sure.
By setting the standards, the ALM office has the obligation to push the organization into a continuous delivery model. Typically the problems stated above are handled in an ad hoc fashion by application experts, without being integrated into an overall strategy required by Corporate IT. Redefining a coherent and streamlined process for new and legacy applications, will set the ground for swift and consistent SW development.
(The content is not connected to my employer or to any software vendor. It only expresses my thoughts on various subject matters related to my field of work.)