hhartley.com
Release Manager
This project builds on some concepts and processes of systems/software development and project management I have learned over the years. There are proven methods to manage large scale distributed projects simply and predictably. This project will provide the background necessary to develop a simple management tool, or a set of processes and templates to employ some of these concepts.
Terminology
Today, most networked service oriented applications are large and distributed across many applications provided by numerous vendors. One of the difficulties in describing these applications is that concepts and systems span multiple domains, and depending on which domain (context) you are considering, terms have a broad variety of meanings. One might consider the following domains: Ownership domains, geographic domains, connectivity domains, physical domains, technology domains, business domains, and so on. When you consider that professionals have varied backgrounds and skills, these domains are often colored by individual perspective and perception. Thus, when using terms like 'project', 'platform', 'program', 'system', 'component', and so on, things become very confused indeed, because everyone has a slightly different perspective on what these terms mean. Therefore, for the purposes of this project, I define relevant terms that follow from the perspective of a service provider and its vendors.
| Term/Concept | Definition |
|---|---|
| Platform | Combination of systems deployed necessary to deliver services to end-users. |
| Project | Effort required to deliver some new functionality to a platform or system. |
| System | Combination of hardware and software providing essential functionality. |
| Feature | Specific capability or functionality. |
| Vendor | Company or group that builds systems. |
| Owner | Individual primarily responsible for a system or project. |
| Provider | Company that delivers services and utilizes vendor systems. |
| Service | Commodity delivered to an end-user typically for a fee. |
| End User | Paying customer, and the consumer of services. |
| Release | A versioned aggregation of software that is certified by its producer as usable. |
Background
The biggest challenge to delivering new services (features and functionality) is that of coordination. Coordination becomes the key consideration when confronted with the following:
- There are multiple lines of business providing services over the same medium.
- Each line of business offers a variety of services over a largely common platform.
- The platform is made up of a number of disparate systems.
- Systems are vendor products, each with differing roadmaps, business models, and strategic interests.
- New technologies are introduced which shift the foundations of the platform.
- Systems are released and deployed frequently and continuously.
- Initiatives and features (projects) are introduced in an ad hoc and re-prioitized continuously.
- There is competition among initiatives for precious few resources.
- Priorities change frequently.
As we can see from the bullet list above, there are many moving parts, and they are not always moving in harmony with one and other. If you consider that each new service or project typically requires changes to two or more systems, and that there are multiple initiatives ongoing simultaneously, you begin to understand the multi-dimensional complexity of deploying new services in an efficient manner.
Projects and Systems
A broadband service provider platform is generally made up of from five to a dozen major systems. At any given time, there may be between 8 and a dozen (or more) projects active. The diagram below depicts the relationship between systems and projects. Projects may require functionality from one or more, but not all subsystems, and each system may require implementation to support one or more projects in addition to new subsystem enhancements and bug fixes.
Projects are introduced in an indiscriminate manner based upon perceived need or opportunity. Typically timeframes are identified as end-points, and the project thrown into the mix with other projects. The project may or may not warrant a project manager. For those that do, project manager will identify a sequence of tasks in Microsoft Project. Those tasks, and the project plan take into account the completion of tasks without regard for other projects that may be required of systems impacted by changes necessary to complete the new project.
Typically the focus and emphasis of large service provider organizations is only on projects. The problem with this approach is that visibility and emphasis of systems and their requirements is absent. The result of which is very weak intra project coordination, and significant churn of new system level features. In essence, there is no system or platform roadmap. Without clarity of system features and timeframes, it is difficult to coordinate system releases to meet the needs of project requirements. Furthermore, subsystem enhancements for bug fixes or improved operations are often overlooked. Thus, if an organization has taken the time to create project plans for multiple simultaneous projects, is it clear what the system impacts are? It depends, but generally the answer is no.
- A lack of focus on system deliverables results in the following:
- Very non-granular (frequent) delivery and release of systems.
- Typically less than adequate testing and validation (due to the high frequency of releases).
- Limited or no emphasis on infrastructure capability and stability improvements.
- Tardy deliveries due to lack of sufficient resources to complete projects.
- Unnecessary development of redundant solutions.
- Lack of consistency across solutions resulting in awkward solutions.
Another problem that slows the delivery of services and features is that requirements are typically not well understood, nor appropriately documented. One solution to this problem would be comprehensive requirements document for every feature across every project. However given the available resources and timeframes, requirements documents are sparse. The lack of documented requirements leads to an uncertainty of which features need to be implemented on which systems in what timeframes. In addition, without requirements, the mapping of business requirements to technical features is lost. Thus no-one can answer the question, what needs to be done on which system to implement this project.
Processes (Lightweight versus Heavyweight)
There are two extremes to managing development and delivery. One is very heavyweight requiring numerous people to manage schedules, requirements, design documents, business cases, test plans, and so on. While philosophically this is the right way to develop and deploy quality systems, it is also cumbersome and costly. The other extreme is a fly by the seat of your pants approach which is ad hoc, where little is documented, and the process whatever it is, varies on a case by case basis. The second approach is much more efficient in terms of time to market and number of resources required to deliver and deploy products, but suffers from less than stellar quality, significant rework, and greater uncertainties.
In practice, companies in the service provider domain function more closely to an ad hoc approach. This makes sense when you consider that these companies are operationally focused. These companies tend to emphasize and focus on delivering new services through advances in embedded consumer devices and network infrastructure. Software and support systems are perceived as an expense, rather than enabling technologies (but I digress, more on this elsewhere on this website). Given this predisposition, the following are generally true:
- Developer resources are rare or nonexistent in these companies.
- Vendors are tasked with the lions share of new development.
- Deployed legacy systems prevail.
- Software development costs are generally embedded in hardware costs.
- Most of the cost of new development is spent on systems integration rather than new services.
This is far different from the software life-cycle for developing a stand alone application, or a simple client server application. For these types of applications traditional project management tools are well suited. There is typically one deliverable, the company employs the developers, and the focus of the project is typically a single application. Thus almost all activities can be tracked and controlled. For broadband service delivery platforms, these advantages are typically not present, and typical tools not well suited. There are many projects, spanning many vendor products. Vendors products tend to be offered to multiple customers, and therefore do not focus solely on the service providers immediate needs. Development resources are typically not visible or accessible. For this a tool other than Microsoft Project is needed.
ReleaseMgr is project and systems management tool, but not in the traditional sense. ReleaseMgr does not focus on gant charts, low level tasking, resource loading, or any of other types of things you would find in a Microsoft project. It focuses on insuring that projects and systems capabilities are well coordinated across releases, and that for each release the person responsible knows what features are necessary to implement.
Assumptions (Real World Observations)
The following represent a points of view which influenced the design of ReleaseMgr:
- Requirements documents will not be created for every project or subsystem. In some cases requirements documents will be created that will lag the design and development of new features. Generally people do not write documents.
- Software developers and other engineering staff are talented human beings, and it is unreasonable to believe that their time can be tracked down to the minute over the course of several months. Priorities change, people have moods, there are numerous interruptions.
- The vast majority of coordination across projects and subsystems occurs in the form of interpersonal communications. Technical staff should be provided with tools that enable them to communicate succinctly about deliverables.
- A lightweight process that tracks items at a block and line item level is better than no process at all, and in most cases more approachable and efficient than a heavyweight process that requires dozens and dozens of lengthily documents to be written. Again, people generally do not write documents. Also, people tend not to read long documents.
- Most organizations do not have the discipline or motivation to follow a highly structured software development lifecycle process.
- Software requirements span domains and levels of abstractions. The requirements people write depends on where they sit in the organization. Development managers tend to write requirements in terms of technical solutions and designs, rather than problems and business objectives. Product managers tend to write requirements in terms of opportunities, but neglect constraints and technical impacts or side effects.
- More predictable release cycles which bundle functionality are beneficial in that they allow more concerted validation, and minimize the cost and disruption of deploying frequently to operational systems.
- Some individuals tend to hide or hoard information. Conversely, other individuals tend to shun information not in their immediate scope. Both characteristics lead to awkward designs, inappropriate redundancies, or nasty surprises.
Solution
This project (named ReleaseMgr) focuses on the management and coordination of projects and subsystems and their features.
- The ReleaseMgr application will provide the following capabilities:
- Track Active Projects.
- Track System Releases.
- Identify Project and System Owners.
- Manage Project Features.
- Manage System Features.
- Manage Project and System across finite and monotonic timeframes.
- Flow-through features from project to subsystems.
There are several additional capabilities that could be considered such as managing resources, priorities, and deployments. Integration with project management, trouble ticketing, and bug tools could also be added. For now Release Manager demonstrates basic concepts. The overriding rule keep it simple.
Roles and Responsibilities
-
The organizational (and process) roles considered by this application are:
- Project Manager - Manages projects. The project manager interfaces with product managers to insure that a product features are understood and documented. The project manager works with the development managers to insure that project features are slated for development on subsystems, and that the subsystems are completed in a timely manner for integration and validation, and ultimately deployment.
- Product Manager - Manages customers expectations and new initiatives. The product manager is a role that is generally a marketing and account management function. The product manager will spawn new projects and insure that these projects are funded and on target for business or customer requirements. In reality, this title is absent in some organizations.
- Development Manager - Manages the development of systems. In some cases this will be a manager of developers responsible for development, in other cases, the development manager will be responsible for managing a vendor and their development of systems. The development manager is responsible insuring that requirements from multiple projects are coordinated in a timeframe.
- Executive - Executives set priorities. The executive will establish priorities through funding and other means. Ultimately the executive will have the final say on which projects are undertaken, and which are not.
Rules
In order to consistently achieve appropriate results a set of rules should be observed.
- Release Manager emphasizes and implements the following rules:
- Projects should be approved by senior management (transcending whatever front-end gates are in place) and given a name that uniquely identifies that project from others.
- Every project undertaken should have only one owner
- Every system should have only one owner
Process
Because costly resources are being utilized to develop, test, and integrate features, it should be possible to answer a simple question when assessing either project or system features. The simple question is this, "Why will we implement this feature?". The answer to that question should be clearly understood, otherwise the feature is suspect.
As system releases and projects are identified they will be assigned to a 'T'. Thus every system release will be assigned to a time segment. Also, projects will be assigned to time segments. As project features are introduced they will be de-composed into system features. As system features are introduced they will be assigned to projects. Thus, every system feature will correlate with one or more projects. Conversely every project will consist of a set of features which can be mapped to subsystem features.
As features are mapped to different projects and systems, there is a natural conflict that occurs between project timeframes and release timeframes. It is up to the owners of their respective projects and management to insure that compromises are made to re-prioritize features and releases to insure that project and system releases are coordinated. In practicality, this means that features must move either forward or backward to insure that releases are aligned. It is up to the owner of the respective project/system to defend their project/system such that their resources are assured of completing a release in a timely manner.
Data Relationships
Screens
T Configurator
Timeframe configuration will allow the administrator to identify initial timeframes and timeframe increments.
Company Configurator
The Company configurator will allow the administrator to create a company entry. This screen will also allow the modification and deletion of companies from the underlying database.
Owner Configurator
The Owner configurator will allow the administrator to create an owner, and assign that owner to a company. The owner configurator will also allow the administrator to make modifications and deletions to owners.
Project Configurator
The project configurator will allow the administrator to create a project and assign an owner to it. The project configurator will also allow the administrator to change project owners, as well as make other project modifications or deletions.
System Configurator
The system configurator will allow the administrator to create systems and assign owners to them. The system configurator will also allow the administrator to change system owners, as well as make other system modifications or deletions.
Project Features Screens
Project Features will identify line item requirements for a specific project release. From the projects screen it shall be possible to identify subsystem features.
System Features Screens
System Features will identify line item requirements for system features. Each feature will be assigned to a system release. From the system features screen it should be possible to assign this feature to a project.
Build Project BOM
Reports
Show Projects by T
Show Systems by T
Show Features by Project
Show Features by System