In bookstores now! (not really)
As promised, this is the "dust cover summary" of what this blog is about. If this sounds interesting, maybe you will periodically come back and read the new installments. If not, then you are no worse off.
Project Integrity Management
Copyright © 2008, M@
January, 2005. After over four years and half a billion dollars, the FBI software system modernization project codenamed Project Trilogy was officially scrapped with no usable functionality to show. Every year, thousands of corporate software development projects around the world slip into the red, running over budget and over schedule. Many of them are scrapped and written off as complete losses while others are released incomplete and buggy. In the software development world, an on-time, on-budget, fully functional project is the exception, not the norm. Why?
Many will argue that software development is just too complex to be reliably managed. Software is typically not held to the same level of scrutiny that hardware projects are, giving much more responsibility to the developers to "do the right thing" in writing the code. In most cases, there aren't even established standards for how software is developed, tested, or deployed. Is it any wonder that problems are common?
But in "Project Integrity Management", the author makes the case that it is not the lack of standards or negligence of the developers that lead to software disasters; it is a lack of project integrity. This is a concept that creates a framework for managing the myriad of components that make up a software project. While most projects have tools and procedures in place for managing schedules, budgets, and source code, the large majority of them do not have anything in place to insure that each change to hardware, software, documentation, or procedures is done in a way that gives full visibility to all levels of the project.
It is the author's point of view that the vast majority of the problems that appear in a development project are the result of subtle changes and differences between the environments used to develop, test and deploy the applications. In a similar manner, the failure to effectively capture client expectations in requirements and manage changes to those requirements causes most of the resource sapping rework that projects seem doomed to go through.
When a project is under integrity management, each piece is accounted for and tracked as a small part of a larger unit. Just as individual wires, bolts, panels and other parts make up engines, dashboards and suspension on a car, each component of a integrity controlled project makes up the operating systems, databases, applications, and configurations. In the same way, just as engines, dashboards, and suspension make up a completed car, operating systems, databases, applications, and configuration make up environments.
This atomic approach to integrity accounting offers a manageable, easy to control framework that insures that the same code that worked in the development environment will work in the test environments and in production environments. It provides a way to insure that all parts are known in all environments, and provides a verifiable method of promotion of ALL changes (application code, hardware, operating system, configuration, etc.) from one environment to the next.
This sounds like a complicated thing to do on the surface. The variety and number of components in most projects is overwhelming, and once ALL changes are truly accounted for, they can come in at a furious pace. But by managing every item in a project as both a unique item and as part of a larger item, the entire project can be mapped and managed as a single, large but organized hierarchal structure. That is the power of Integrity Management!
-M@
Project Integrity Management
Copyright © 2008, M@
January, 2005. After over four years and half a billion dollars, the FBI software system modernization project codenamed Project Trilogy was officially scrapped with no usable functionality to show. Every year, thousands of corporate software development projects around the world slip into the red, running over budget and over schedule. Many of them are scrapped and written off as complete losses while others are released incomplete and buggy. In the software development world, an on-time, on-budget, fully functional project is the exception, not the norm. Why?
Many will argue that software development is just too complex to be reliably managed. Software is typically not held to the same level of scrutiny that hardware projects are, giving much more responsibility to the developers to "do the right thing" in writing the code. In most cases, there aren't even established standards for how software is developed, tested, or deployed. Is it any wonder that problems are common?
But in "Project Integrity Management", the author makes the case that it is not the lack of standards or negligence of the developers that lead to software disasters; it is a lack of project integrity. This is a concept that creates a framework for managing the myriad of components that make up a software project. While most projects have tools and procedures in place for managing schedules, budgets, and source code, the large majority of them do not have anything in place to insure that each change to hardware, software, documentation, or procedures is done in a way that gives full visibility to all levels of the project.
It is the author's point of view that the vast majority of the problems that appear in a development project are the result of subtle changes and differences between the environments used to develop, test and deploy the applications. In a similar manner, the failure to effectively capture client expectations in requirements and manage changes to those requirements causes most of the resource sapping rework that projects seem doomed to go through.
When a project is under integrity management, each piece is accounted for and tracked as a small part of a larger unit. Just as individual wires, bolts, panels and other parts make up engines, dashboards and suspension on a car, each component of a integrity controlled project makes up the operating systems, databases, applications, and configurations. In the same way, just as engines, dashboards, and suspension make up a completed car, operating systems, databases, applications, and configuration make up environments.
This atomic approach to integrity accounting offers a manageable, easy to control framework that insures that the same code that worked in the development environment will work in the test environments and in production environments. It provides a way to insure that all parts are known in all environments, and provides a verifiable method of promotion of ALL changes (application code, hardware, operating system, configuration, etc.) from one environment to the next.
This sounds like a complicated thing to do on the surface. The variety and number of components in most projects is overwhelming, and once ALL changes are truly accounted for, they can come in at a furious pace. But by managing every item in a project as both a unique item and as part of a larger item, the entire project can be mapped and managed as a single, large but organized hierarchal structure. That is the power of Integrity Management!
-M@
[0] Comments:
Post a Comment
<< Home