Managing a complex solution roll-out using Rational Team Concert
Summary
This article focuses on the project planning and management capabilities of IBM Rational Team Concert showing how it was used to manage and deliver the roll-out of an enterprise wide application lifecycle management solution. The article shows how IBM Rational Team Concert can be used to streamline the communication between 3 teams involved in a deployment project: the end users of the client, the deployment team of IBM Rational Software and the Support and Development organization of IBM Rational Software.
Introduction
The wind of change is blowing in many organizations today. Organizations must optimize the development process, improve productivity to be able to drive change and deliver at the speed the market demands. The deployment of a new development environment in such a context means much more than just deploying new tools.
For an established enterprise, there is no out of the box solution – usually an existing one needs to be adapted to specific requirements, which in turn may introduce changes to the underlying infrastructure. The experience shows that transforming the (tool) environment without changing or optimizing existing methods or processes will commonly fail to deliver the expected return of investment. That implies that the methods must be changed as well – on small or large scale – depending on the goals of the transformation process.
Once the new development environment, the new methods and processes are in place, the users will need enablement which calls for appropriate training courses and mentoring delivered by the IBM deployment team.
Both the client and the IBM team need to ensure that adoption of the tools is safeguarded in order to avoid that the investment in the new environment will get at risk. The organization is likely to change as new roles, such as tool specific focal points, are introduced. To be successful in the introduction of the new technology, a local center of excellence needs to be established as well – this will take responsibility for future operation and refinement of the environment when the IBM deployment team have finished their work.
Consequently, there are many dimensions to be considered when introducing a new development environment- as outlined in Figure 1 [Eeles 2011] – the methods, the tools, the training, the organization, the infrastructure and the adoption.
Figure 1. Transforming an Organization
In this paper we shall show you how IBM Rational Team Concert has been successfully used to support the deployment of a systems and software development environment in a complex project. The three areas covered were:
Background and evolution of the solution
The current experiences using IBM Rational Team Concert for managing a complex solution roll-out stems from a large deployment project. The project started out using an instance of IBM Rational Team Concert called “Delivery Excellence” [Aunkofer et all 2011] for managing deployment projects supporting 4 delivery phases: pre-sales, project setup, delivery and project closing (see Figure 2).
Figure 2. Delivery Excellence Phases
The IBM Rational Team Concert process template for Delivery Excellence provided basic features handling work items (such as Tasks, Defects, Enhancements etc.), project plans, client contacts, project deliverables and the project control book.
The adoption of IBM Rational Team Concert followed in several waves as the project unfolded:
Deployment Team Collaboration
Agile development is characterized (amongst others) by being iterative and incremental. What makes it interesting for deployment contracts on a time and material basis is the adaptive nature of agile development and project management. Two aspect are of key interest in typical deployment projects [IBM 2008].
IBM Rational Team Concert is well suited for this purpose and has been effectively used to support the main use cases shown in Figure 3. We shall shortly introduce the capabilities one by one in the remainder of this section.
Figure 3. Deployment Team Use Cases
One key feature of the project management capabilities is Work Item Management, which allows the IBM deployment team to create, assign, track and follow up on planned as well as ad-hoc activities. Work items in form of simple tasks have a title, description, assigned owner, priority and iteration (Planned For). See Figure 4 for an example. The work items have an underlying workflow with states and state transitions. Tasks are originally in state New, but can be transitioned to state In Progress when work starts, and finally ends up in being in state Closed or Dismissed. Comments can furthermore be added to the work item in case that there is something important that need to be kept for the record – such as e.g. agreements with the client, important constraints, lessons learned etc.
Figure 4. Work Item Sample
Keeping track of work items helps in answering questions such as: What do we still need to do as team? What must I do, and what are the priorities of my work? What is currently being worked on? What kind of new tasks have appeared that requires the team’s attention? The answer to the second question is directly delivered by the To Do list in Figure 5.
The use of IBM Rational Team Concert was combined with daily stand-up meetings to discuss status, next steps and impediments (technical as well as organizational). Such meetings have resulted in new work items being created or existing work items being closed or dismissed.
A large deployment project with a duration of several quarters may end up having several deployment iterations (deploying the tools iteratively), as well as iterations dedicated to knowledge transition and finally ongoing on-demand support. The work items relevant for an iteration can effectively be organized and managed using the project planning features of IBM Rational Team Concert.
An iteration plan with a corresponding work breakdown structure is shown in Figure 6. Major work-packages that were defined in planning the iteration such as “Upgrade solution to latest version” are represented in terms of parent work items, with associated and more detailed child work items such as “Upgrade RDM Server to 5.0.2”. The current view has been defined to only show open work items, i.e. completed work items are consequently not rendered in the current view.
Figure 6. Deployment Iteration Plan
Using the project planning features of IBM Rational Team Concert it is quite easy to determine what is in scope for the current iteration and which work items are remaining to complete the iteration. Moreover, it would be possible to postpone work items to the next iteration if needed simply by changing the “Planned For” attribute of the work item. This is typically something that may happen when the end of an iteration is approaching and it is realized that not all remaining work can indeed be completed within that iteration. Work items are then either moved to the next iteration or discarded if they are of low priority or have become superfluous for any reason.
There is more to project management than just keeping track of iteration plans and associated work items. The used instance of IBM Rational Team Concert can be used to manage all Project Control Book artifacts such as contracts, memory of meetings, requirements etc. (see Figure 7). These are basically documents containing information that supplements the information directly available in the work items.
Work items may produce deliverables of the project e.g. in form of documents, custom training material, plug-ins to the deployed tools or custom reports – just to mention a few. Rather than having these deliverables stored somewhere on the file system and out of project context, it is possible to upload them to IBM Rational Team Concert. Such an upload always happens in relation to a work item of type Asset.
Figure 7. Project Management Control Book Managing Collaboration with the Client Team
The change that the deployment of new tools brings into an organization requires streamlined collaboration and communication with the end users. All too often individual users may run into issues that are not communicated or not disclosed in a timely manner. Whether the issue is due to a wrong usage, limited know-how of the user, a tool issue or a tool limitation is something that is best clarified by an expert of the deployment team. However, if not communicated, the likelihood that the issue will be solved is significantly decreased. Moreover, even if the issue is communicated and resolved, e.g. by direct communication between the end user and a tool specialist, the chance is still there that the solution to the issue is not shared with the larger team.
Figure 8. Client Collaboration Use Cases
Communication between the users adopting the new tools and the team of specialists that are in the process of introducing the tools in a client’s organization can be improved by using IBM Rational Team Concert as well. The focus of the current solution is on ad-hoc activities needed for enablement and adoption that supplements the planned activities by addressing impediments that appear during tool usage. Client collaboration is supported by a set of basic use cases (see Figure 8): an end user may report an issue with a tool by creating a new work item of type Issue, whereas an IT specialist will resolve the issue (if possible) and document the solution. Notice that the use case diagram defines the roles. Initially, the role of the tool specialist will naturally be taken by a member of the IBM deployment team. However, the idea is that knowledge shall be transferred to the end users, so this role can eventually be taken over by designated focal points in the client’s organization.
Figure 9. Client Collaboration Dashboard
The entire process of managing the collaboration between end users and the deployment team can be adequately supported using a dashboard such as the “Client Collaboration” dashboard in Figure 9.
The dashboard shows the open and closed issues for each tool in the two widgets to the left of the dashboard. Many tools are being adopted at once in this project so the amount of issues is not in itself alarming, but the dashboard tells a project manager that some focus seems to be required in supporting the use of IBM Rational Design Manager (RDM), Rational Team Concert (RTC) and Rational Software Architect (RSA).
The widgets in the middle and to the right on the other hand show the open issues per tool. This information is important for the IT Specialists on the deployment team. A tool specialist will typically be responsible for deploying a specific tool (say RTC) and the widget titled “Open RTC Issues” clearly informs the responsible specialist where actions are required. This means that the specialist will look for new work items in the relevant widget of the dashboard, assign the work item to himself and start work on the issue (the latter may of course require some interactions with project management first in order to get the approval to work on the issue right away). The user will be notified when changes to the issue appears and can then view the conclusion of the problem analysis – i.e. whether the issue is due to wrong usage, an improper configuration or a defect (just to mention a few possible outcomes of the analysis) .
Of course, it is also possible for a user to search for existing issues being reported by other users to see if the problem is new or has already been resolved. The system also provides the set of users with a light-weight asset management system akin to the one for project management, which allow sharing of documents and deliverables such as user guides, tech-notes, manuals, deliverables or other kind of documents within a team. These documents can conveniently be linked to the relevant work items in case that a more comprehensive description of the solution is required.
Figure 10. Support Collaboration Use Cases
Opening a PMR does not necessarily mean that the problem is due to a defect. Support will analyze the issue – possibly in cooperation with 2nd or 3rd line support (development) – and then determine if it is a usage problem, a configuration issue, an Request for Enhancement (RFE) or indeed a defect. Having created the RFE the team member needs to create a work item in the system so that progress on the defect or enhancement request can be tracked. In case that a problem prevents a successful deployment, the IBM deployment team may request a hot fix to be created.
The initial solution implemented PMRs as regular tasks using tags to designate the tool impacted by the PMR as well as the resolution to the PMR. Later on a new process template has been created where the designated tool as well as the resolution of the PMR are defined using custom work item attributes. This way it becomes more convenient to define the appropriate dashboards such as the “Support Collaboration” dashboard shown in Figure 11.
Figure 11. Support Collaboration Dashboard
Keeping track of different work item types, helps answering questions such as: How many open PMRs do we have? Who is taking care of them? What are the critical/blocking PMRs that may have impact on the overall roll-out? What are the action items of development that are still open (these are the enhancement requests and the defects)? The open PMRs and closed PMRs are shown to the left in the dashboard – almost akin to the “Client Collaboration” dashboard. The widget titled “Open PMRs” can give some sort of indication if there are any hotspots in the project needing attention. The widget “Closed PMRs” on the other hand provides some information about the cause of past problems, i.e. if they are caused by product limitations or wrong usage of the tools. The remaining widgets on the dashboard shows the open enhancement requests, open defects and open PMRs still needing attention of the deployment team in moving forward.
The various work items related to problem management can be linked together to allow inter/dependencies tracking. A PMR may for example be linked to the associated enhancement request or defect. Managing such inter-dependencies between work items is well supported by the linking features of the IBM Rational Team Concert.
Another advantage of using IBM Rational Team Concert is that it can be customized very easily to provide new dashboards, such as the consolidated “Deployment Team Collaboration” dashboard in Figure 12, which shows teams, issues, open work item distribution per team and PMRs in a single dashboard.
Figure 12. Consolidated Dashboard
This project template defines 3 team areas: one for managing communication with the client (blue classes), another for managing the deployment activities (green classes) and a third for managing the collaboration with support and development. The project template is furthermore available in two versions: one as an extension of the formal project template for more traditional project planning (including risk management) and another on top of the agile project template for more agile projects. These templates can then be adopted and customized as needed by individual organizations interested in the approach.
Figure 13. Underlying Data Model
Once that an administrator has created a project area using the template, several administrative tasks need to be carried out next before the project area is ready for use. The administrator must create users, define their roles, associate them with team areas, adjust the dashboards according to project needs and create the iteration plans as well as the initial folder structure needed for managing documents such as the Project Control Book. These administrative work items are created automatically when the project area is created.
One of the administrative work items is of special nature. The approach for managing the deployment activities took its origin in the “Delivery Excellence” initiative, which defined mandatory and optional activities of the deployment team for each deployment phase (see Figure 2), such as “Access customer requirements” (Pre-sales phase), “Conduct kickoff meeting” (Project setup phase) and “Conduct lessons learned workshop” (Project closing phase). We have taken the decision to define such predefined work items in an Microsoft Excel sheet and then let the administrator import the Excel sheet into IBM Rational Team Concert. The advantage of doing so is that it is quite flexible to provide project specific variants depending on the nature and size of the project: it is simply a matter of changing the Excel sheet before it is imported.
One last remark: We have put almost no work in defining formal workflows for the various work items. We did not want to enforce a predefined process on the projects dictating how issues, deployment tasks and PMRs should be handled for the simple reason that “one size would hardly fit all projects”. Deployment projects are very different in nature since the clients have different processes and expectations which will surely impact the way in which issues are treated. For example: can an IT Specialist just start work on resolving an issue right away (if it is covered by an activity of the current iteration), or would he need approval by project management first? The latter could involve two approvals: one of the clients project manager and one of the IBM deployment team coordinator. This policy may vary from project to project and the potential of reuse is low. We have therefore kept workflows simple and focused on providing the necessary functionality for managing the work items and for viewing the status in the dashboards.
It should be noted that the approach extend beyond using it in the phases where the IBM deployment team is responsible for deploying the tools. It can equally well be used by a clients center of excellence to maintain and refine the development environment, e.g. by planning future upgrades or by managing the interaction with IBM support as well as managing the collaboration with the users in the clients organization.
Authorship
The kernel project management capabilities were originally designed and implemented by the Rational ISSR Delivery Excellence team, the initial system for client collaboration by Kristina Estela Florea and the capabilities for managing the collaboration with support and development by Dr. Einar W. Karlsen, who also revised and refined the capabilities for managing work items of the deployment team.
[Eeles 2011] Peter Eeles: Define the scope of your development environment, developer Works, 2011. http://www.ibm.com/developerworks/rational/library/define-scope-development-environment/index.html.
[IBM 2008] IBM Project Management Center of Excellence: Introduction to managing agile projects at IBM, November 2008.
In this paper we shall show you how IBM Rational Team Concert has been successfully used to support the deployment of a systems and software development environment in a complex project. The three areas covered were:
- Project Management where IBM Rational Team Concert has been used to define appropriate iterations plans for all the phases and disciplines of the deployment project. To avoid that important activities are forgotten or addressed too late, work items must be created, assigned, carried out and tracked in each and every area – for planned as well as ad-hoc activities. To improve performance as the project unfolds, appropriate means for supporting e.g. retrospective analysis must be established as well.
- Client Collaboration where IBM Rational Team Concert has been used to improve tool adoption and communication between the users in the client organization and the IBM deployment team. All too often users do not report issues or obstacles in using a new tool in a timely manner which may lead to frustration in the organization and jeopardize the adoption of the tool. This problem can be addressed by allowing users to create ad-hoc tasks and issues in terms of work items for the IBM deployment team to address.
- Support Collaboration where IBM Rational Team Concert has been used to manage Problem Management Reports (PMRs) and related artifacts needing attention by the IBM deployment team. PMRs are basically considered work items that need to be addressed by dedicated team member in a timely manner. This includes tracking of open PMRs, unresolved defects and open requests for enhancements (RFEs) – amongst others.
Background and evolution of the solution
The current experiences using IBM Rational Team Concert for managing a complex solution roll-out stems from a large deployment project. The project started out using an instance of IBM Rational Team Concert called “Delivery Excellence” [Aunkofer et all 2011] for managing deployment projects supporting 4 delivery phases: pre-sales, project setup, delivery and project closing (see Figure 2). Figure 2. Delivery Excellence Phases
The IBM Rational Team Concert process template for Delivery Excellence provided basic features handling work items (such as Tasks, Defects, Enhancements etc.), project plans, client contacts, project deliverables and the project control book.
The adoption of IBM Rational Team Concert followed in several waves as the project unfolded:
- Wave 1: Work Item Management to track and follow up on planned as well as ad-hoc activities, combined with management of deliverables and internal project control book artifacts such as meeting minutes.
- Wave 2: Handling of Problem Management Reports as regular work items in IBM Rational Team Concert as a proficient replacement of Microsoft Excel.
- Wave 3: Definition of Iteration Plans for the deployment using the planning capabilities of IBM Rational Team Concert.
- Wave 4: Introduction of Infocenter Rational to improve collaboration between users in the client organization and the IBM deployment team by having the client team creating issues and tasks for the IBM deployment team whenever needed.
- Wave 5: Extended Problem Management including management of Requests for Enhancements, Issues and Patches/Hot-fixes in a more systematic way.
Deployment Team Collaboration
Agile development is characterized (amongst others) by being iterative and incremental. What makes it interesting for deployment contracts on a time and material basis is the adaptive nature of agile development and project management. Two aspect are of key interest in typical deployment projects [IBM 2008].- “Evolutionary iterative development“, which implies that the requirements, plan, estimates, and solution evolve or are refined over the course of the iterations rather than being fully defined and “frozen” in a major up-front specification effort before the development iterations begin.
- “Adaptive development“, which implies that elements adapt in response to feedback from previous work from users, tests, developers, and so on. The intent is the same as that of evolutionary development, but the name more strongly suggests the feedback-response mechanism in evolution.
IBM Rational Team Concert is well suited for this purpose and has been effectively used to support the main use cases shown in Figure 3. We shall shortly introduce the capabilities one by one in the remainder of this section.
Figure 3. Deployment Team Use Cases
Figure 4. Work Item Sample
Keeping track of work items helps in answering questions such as: What do we still need to do as team? What must I do, and what are the priorities of my work? What is currently being worked on? What kind of new tasks have appeared that requires the team’s attention? The answer to the second question is directly delivered by the To Do list in Figure 5.
Figure 5. My To Do List
The use of IBM Rational Team Concert was combined with daily stand-up meetings to discuss status, next steps and impediments (technical as well as organizational). Such meetings have resulted in new work items being created or existing work items being closed or dismissed.
A large deployment project with a duration of several quarters may end up having several deployment iterations (deploying the tools iteratively), as well as iterations dedicated to knowledge transition and finally ongoing on-demand support. The work items relevant for an iteration can effectively be organized and managed using the project planning features of IBM Rational Team Concert.
An iteration plan with a corresponding work breakdown structure is shown in Figure 6. Major work-packages that were defined in planning the iteration such as “Upgrade solution to latest version” are represented in terms of parent work items, with associated and more detailed child work items such as “Upgrade RDM Server to 5.0.2”. The current view has been defined to only show open work items, i.e. completed work items are consequently not rendered in the current view.
Figure 6. Deployment Iteration Plan
Using the project planning features of IBM Rational Team Concert it is quite easy to determine what is in scope for the current iteration and which work items are remaining to complete the iteration. Moreover, it would be possible to postpone work items to the next iteration if needed simply by changing the “Planned For” attribute of the work item. This is typically something that may happen when the end of an iteration is approaching and it is realized that not all remaining work can indeed be completed within that iteration. Work items are then either moved to the next iteration or discarded if they are of low priority or have become superfluous for any reason.
There is more to project management than just keeping track of iteration plans and associated work items. The used instance of IBM Rational Team Concert can be used to manage all Project Control Book artifacts such as contracts, memory of meetings, requirements etc. (see Figure 7). These are basically documents containing information that supplements the information directly available in the work items.
Work items may produce deliverables of the project e.g. in form of documents, custom training material, plug-ins to the deployed tools or custom reports – just to mention a few. Rather than having these deliverables stored somewhere on the file system and out of project context, it is possible to upload them to IBM Rational Team Concert. Such an upload always happens in relation to a work item of type Asset.
Figure 7. Project Management Control Book
Managing Collaboration with the Client Team
The change that the deployment of new tools brings into an organization requires streamlined collaboration and communication with the end users. All too often individual users may run into issues that are not communicated or not disclosed in a timely manner. Whether the issue is due to a wrong usage, limited know-how of the user, a tool issue or a tool limitation is something that is best clarified by an expert of the deployment team. However, if not communicated, the likelihood that the issue will be solved is significantly decreased. Moreover, even if the issue is communicated and resolved, e.g. by direct communication between the end user and a tool specialist, the chance is still there that the solution to the issue is not shared with the larger team.Figure 8. Client Collaboration Use Cases
Communication between the users adopting the new tools and the team of specialists that are in the process of introducing the tools in a client’s organization can be improved by using IBM Rational Team Concert as well. The focus of the current solution is on ad-hoc activities needed for enablement and adoption that supplements the planned activities by addressing impediments that appear during tool usage. Client collaboration is supported by a set of basic use cases (see Figure 8): an end user may report an issue with a tool by creating a new work item of type Issue, whereas an IT specialist will resolve the issue (if possible) and document the solution. Notice that the use case diagram defines the roles. Initially, the role of the tool specialist will naturally be taken by a member of the IBM deployment team. However, the idea is that knowledge shall be transferred to the end users, so this role can eventually be taken over by designated focal points in the client’s organization.
Figure 9. Client Collaboration Dashboard
The entire process of managing the collaboration between end users and the deployment team can be adequately supported using a dashboard such as the “Client Collaboration” dashboard in Figure 9.
The dashboard shows the open and closed issues for each tool in the two widgets to the left of the dashboard. Many tools are being adopted at once in this project so the amount of issues is not in itself alarming, but the dashboard tells a project manager that some focus seems to be required in supporting the use of IBM Rational Design Manager (RDM), Rational Team Concert (RTC) and Rational Software Architect (RSA).
The widgets in the middle and to the right on the other hand show the open issues per tool. This information is important for the IT Specialists on the deployment team. A tool specialist will typically be responsible for deploying a specific tool (say RTC) and the widget titled “Open RTC Issues” clearly informs the responsible specialist where actions are required. This means that the specialist will look for new work items in the relevant widget of the dashboard, assign the work item to himself and start work on the issue (the latter may of course require some interactions with project management first in order to get the approval to work on the issue right away). The user will be notified when changes to the issue appears and can then view the conclusion of the problem analysis – i.e. whether the issue is due to wrong usage, an improper configuration or a defect (just to mention a few possible outcomes of the analysis) .
Of course, it is also possible for a user to search for existing issues being reported by other users to see if the problem is new or has already been resolved. The system also provides the set of users with a light-weight asset management system akin to the one for project management, which allow sharing of documents and deliverables such as user guides, tech-notes, manuals, deliverables or other kind of documents within a team. These documents can conveniently be linked to the relevant work items in case that a more comprehensive description of the solution is required.
Managing Collaboration with the Support Team
No vendor is keen on admitting that their products may have problems. However, it is an inevitable fact of life that problems may occur during complex roll-outs that can’t – in a first instance – be resolved by the local deployment team. As a result, from a project management perspective, this non-ideal aspect of life must be considered and managed in a proper way. If the local deployment team realize that they can’t solve an issue on their own, there are at least two channels of support that can be used: 1) filing a Problem Management Report (PMR) to Rational Support which will then take over the handling of the problem, or 2) file a work item on Jazz.net.Figure 10. Support Collaboration Use Cases
Opening a PMR does not necessarily mean that the problem is due to a defect. Support will analyze the issue – possibly in cooperation with 2nd or 3rd line support (development) – and then determine if it is a usage problem, a configuration issue, an Request for Enhancement (RFE) or indeed a defect. Having created the RFE the team member needs to create a work item in the system so that progress on the defect or enhancement request can be tracked. In case that a problem prevents a successful deployment, the IBM deployment team may request a hot fix to be created.
The initial solution implemented PMRs as regular tasks using tags to designate the tool impacted by the PMR as well as the resolution to the PMR. Later on a new process template has been created where the designated tool as well as the resolution of the PMR are defined using custom work item attributes. This way it becomes more convenient to define the appropriate dashboards such as the “Support Collaboration” dashboard shown in Figure 11.
Figure 11. Support Collaboration Dashboard
Keeping track of different work item types, helps answering questions such as: How many open PMRs do we have? Who is taking care of them? What are the critical/blocking PMRs that may have impact on the overall roll-out? What are the action items of development that are still open (these are the enhancement requests and the defects)? The open PMRs and closed PMRs are shown to the left in the dashboard – almost akin to the “Client Collaboration” dashboard. The widget titled “Open PMRs” can give some sort of indication if there are any hotspots in the project needing attention. The widget “Closed PMRs” on the other hand provides some information about the cause of past problems, i.e. if they are caused by product limitations or wrong usage of the tools. The remaining widgets on the dashboard shows the open enhancement requests, open defects and open PMRs still needing attention of the deployment team in moving forward.
The various work items related to problem management can be linked together to allow inter/dependencies tracking. A PMR may for example be linked to the associated enhancement request or defect. Managing such inter-dependencies between work items is well supported by the linking features of the IBM Rational Team Concert.
Another advantage of using IBM Rational Team Concert is that it can be customized very easily to provide new dashboards, such as the consolidated “Deployment Team Collaboration” dashboard in Figure 12, which shows teams, issues, open work item distribution per team and PMRs in a single dashboard.
Figure 12. Consolidated Dashboard
Realization
During the initial solution roll-out we have used two project areas – one for managing the external collaboration with the client and another one for managing the iteration plans and the collaboration with support and development. To enable a higher degree of re-use in future projects the decision was taken to produce one consolidated project template. The data model outlining the main classes (plans and work items), their custom attributes and their links are shown in Figure 13.This project template defines 3 team areas: one for managing communication with the client (blue classes), another for managing the deployment activities (green classes) and a third for managing the collaboration with support and development. The project template is furthermore available in two versions: one as an extension of the formal project template for more traditional project planning (including risk management) and another on top of the agile project template for more agile projects. These templates can then be adopted and customized as needed by individual organizations interested in the approach.
Figure 13. Underlying Data Model
Once that an administrator has created a project area using the template, several administrative tasks need to be carried out next before the project area is ready for use. The administrator must create users, define their roles, associate them with team areas, adjust the dashboards according to project needs and create the iteration plans as well as the initial folder structure needed for managing documents such as the Project Control Book. These administrative work items are created automatically when the project area is created.
One of the administrative work items is of special nature. The approach for managing the deployment activities took its origin in the “Delivery Excellence” initiative, which defined mandatory and optional activities of the deployment team for each deployment phase (see Figure 2), such as “Access customer requirements” (Pre-sales phase), “Conduct kickoff meeting” (Project setup phase) and “Conduct lessons learned workshop” (Project closing phase). We have taken the decision to define such predefined work items in an Microsoft Excel sheet and then let the administrator import the Excel sheet into IBM Rational Team Concert. The advantage of doing so is that it is quite flexible to provide project specific variants depending on the nature and size of the project: it is simply a matter of changing the Excel sheet before it is imported.
One last remark: We have put almost no work in defining formal workflows for the various work items. We did not want to enforce a predefined process on the projects dictating how issues, deployment tasks and PMRs should be handled for the simple reason that “one size would hardly fit all projects”. Deployment projects are very different in nature since the clients have different processes and expectations which will surely impact the way in which issues are treated. For example: can an IT Specialist just start work on resolving an issue right away (if it is covered by an activity of the current iteration), or would he need approval by project management first? The latter could involve two approvals: one of the clients project manager and one of the IBM deployment team coordinator. This policy may vary from project to project and the potential of reuse is low. We have therefore kept workflows simple and focused on providing the necessary functionality for managing the work items and for viewing the status in the dashboards.
Conclusion
Managing the various phases, deployment tasks and stakeholder requirements in a complex solution roll-out is a challenging task in itself. The dynamic nature of such an endeavor with the inherent agile nature in form of scope that changes according to user requests, issues coming up etc. calls for a firm management of communication as well as streamlined steering and control. We have found that the IBM Rational Team Concert can be customized and used very efficiently in this context to manage the collaboration between end users, the members of the IBM deployment team and IBM support and development organization.It should be noted that the approach extend beyond using it in the phases where the IBM deployment team is responsible for deploying the tools. It can equally well be used by a clients center of excellence to maintain and refine the development environment, e.g. by planning future upgrades or by managing the interaction with IBM support as well as managing the collaboration with the users in the clients organization.
Authorship
The kernel project management capabilities were originally designed and implemented by the Rational ISSR Delivery Excellence team, the initial system for client collaboration by Kristina Estela Florea and the capabilities for managing the collaboration with support and development by Dr. Einar W. Karlsen, who also revised and refined the capabilities for managing work items of the deployment team.References
[Aunkofer et all 2011] H. Aunkofer, A. Dudler, M. Lokietsch, W. Reintelseder, W. Rothe, M. Stadlbauer: ISSR Delivery Excellence User’s Guide for Rational Team Concert Web Interface V 1.0, Rational Software 2011.[Eeles 2011] Peter Eeles: Define the scope of your development environment, developer Works, 2011. http://www.ibm.com/developerworks/rational/library/define-scope-development-environment/index.html.
[IBM 2008] IBM Project Management Center of Excellence: Introduction to managing agile projects at IBM, November 2008.
About the authors
Kristina Estela Florea has been with IBM Rational Software over 6 years working as IT Specialist for Requirement, Change and Architecture Management. She is currently Community of Practice Leader for the Bluemix Cloud solution within the IBM Rational organization in Germany.
Dr. Einar Karlsen has been with Rational Software since 1998 supporting clients in the adoption of tools and methods for Requirement, Architecture and Test Management and is currently working as Solution Architect for Application Lifecycle Management solutions within the IBM Rational organization. He is currently Technical Lead for reporting within the IBM Rational organization in Germany.
Copyright © 2015 – IBM Corporation