How Emerging Tools Can Support Traditional Project Management Tools

Abstract

In large projects, scheduling has always been challenging for project managers. With traditional project management tools, managers are often engaged with a high number of activities and resources. After dedicating long nights and days to planning and developing a consistent and shared plan, they often discover that tracking the plan becomes expensive and nearly impossible.

With this type of monolithic approach, a path to Agile methods and techniques can hardly be considered. In this case study project, a 35 million euro project for a large Italian customer in the Telco industry, we decided to address that problem by introducing a specific Schedule Model. In our Schedule Model, under the standards provided by the PMBOK® Guide and Practice Standard for Scheduling (PMI, 2011), we could handle different components with the most appropriate tool. We created an integrated mix of traditional project management tools and emerging lean tools typically used for Agile projects and “task and people management” and made them cooperative.

The generalization of the practice is based on the idea of breaking down the project work to work package level and handling the information at this level with a traditional project management tool. Work packages (WPs) are then automatically imported into the task and people management tool. Here WPs are broken down into activity list and assigned to the community of resources. In this way, teams deal only with the Agile tool, reporting on the finished work with any change to activities or risks. Alignment processes between the tools have been realized.

This paper and presentation introduce the real case, the evaluated alternatives, and the experience on how emerging agile tools could be integrated with traditional PM tools.

Company and Authors Presentation

Nexen Business Consultants has been listed in the PMI's Consultant Registry since 2011.

Nexen Business Consultants (www.nexen.it; www.nexenprojectmanagement.it) was founded under another name in 1995 by Gianni Fuolega, who initially managed it to serve the niche market of ERP systems consulting inside the larger Italian banking market. In 2005, his company merged with Engineering as a qualified partner in the banking industry. Since then, Nexen has become the consulting company of Engineering, with Gianni Fuolega acting as the Chief Executive Officer of the company.

Engineering (www.eng.it) is a 6,500-employee Italian company posting €750 million annual revenue. It is organized into Directorates that serve different industries. Inside Engineering, Nexen acts as an agglomerate of Competence Centres, with each cultivating a specific competence providing both presale and delivery activities. Competences Nexen grows and takes care of are (a) Strategy and Financial Advisory; (b) Enterprise Governance and Risk Management frameworks and Accounting Systems; (c) Business Process Management & Reengineering; (d) Project Management & Change Management; (e) IT Governance & Strategy. Nexen internal organization is by competence and each competence Business Unit is led by a Director who coordinates her/his team's efforts with other Business Units to best serve our customers.

Focusing on Change and Project Management competence, Nexen over the last seven years has built a 35-person team specializing in Project Management discipline. Nexen offers its customers different kind of services: (a) PMO teams supporting projects – traditional and agile; (b) PMO teams supporting divisions or directorates - traditional; (c) virtual PMO and project managers communities; (d) enterprise project portfolios initialization and management; (e) project managers certified; (f) consulting services in project and program management and in organizational project management; and (g) training services and preparation for PMP and PMI-ACP certifications.

Part I – Focus on Traditional Scheduling and Agile/Lean Project Management and Tools

I.1 – Recall of Scheduling Principles

The Schedule Model as presented in the Practice Standard for Scheduling – Second Edition

PMI's Practice Standard for Scheduling – Second Edition builds upon the foundation established by the first edition, describing the methods related to scheduling which are generally recognized as good practice for most projects. The practice standard is designed to provide project management practitioners, who are familiar with the PMBOK® Guide, with a summary of the benefits and advantages of a well-developed and maintained schedule model.

“Schedule development flows from the selection of an appropriate scheduling method followed by selection and use of a scheduling tool. Next, project-specific data is entered into the scheduling tool to produce the schedule model. From there, instances of the schedule model are saved for use as what-if platforms, targets, and for formal approval as a baseline. From these instances, various presentations are produced for a wide range of uses. Project scheduling is the application of skills, techniques, and intuition acquired through knowledge and experience to develop effective schedule models” (PMI, 2011).

“The definition stated by PMI is the following: A schedule model is a dynamic representation of the plan for executing the project activities developed by the project stakeholders, applying a selected scheduling method to a scheduling tool using project-specific data.

The schedule model supports the project by allowing for:

• Time phasing and required activities
• Mobilization of resources in a most efficient manner
• Coordination of events within the project and between other projects
• Early detection of risks or problems
• Implementation of actions to achieve the project objectives as planned
• “what-if” analysis
• Resource planning
• Forecasting of estimate at completion

The purpose of the schedule model is to provide a useful detailed plan that can be used by the project manager and the project team to assist them in completing the project successfully. The schedule model describes the work to be done (what), the resources required to do the work (who), and the optimum activity sequence including activity starts, finishes, and relationships (when). The way to do the work (how) is defined by other documents in the overall project plan. Establishing a realistic and achievable schedule model is one of the initial actions” (PMI, 2011).

In the real case we present, we will demonstrate how we kept “what” and “when” separated by the “who.” While “what” and “when” were stored and managed in the traditional project management tool, “who” were stored and managed in the lean/agile tool. Information is flowing between the two tools in order for the project management team and the project manager to assess project performance.

Network diagram and critical path to handle tracking

The most common scheduling method, supported by all major scheduling tools, is the precedence diagram method (PDM). With this common and pervasive usage, it is often referred to as the critical path method (CPM).

The precedence diagram method was introduced initially as a “non-computerized approach to scheduling” offering a cleaner, easier to follow, graphical representation of the network; it depicted the activities involved in a project as boxes or nodes and beside the finish-to-start one introduced enhanced logical relationships and the use of leads and lags. The resulting output is a precedence diagram, also known as project network diagram.

To establish a meaningful critical path it is necessary to develop a logic-based network of activities and milestones with empirically derived durations for execution in a realistic and practical manner. Open ends in a schedule are those activities that lack a predecessor and/or a successor activity, thereby creating a hole or gap in the schedule logic from project start to finish. The only open ends that should be expected are the project start and the project finish milestones. The use of constraints, including leads and lags, should be restricted to those conditions that cannot be adequately defined and modelled by the application of activity logic.

In the real case we are going to present, we will discover that:

• The project network diagram correctness - no open ends except for project start and project finish milestones and only really necessary leads and lags among all 600 activities and 220 milestones of the schedule model - was checked using a tools of Schedule Validation. These kinds of tools are usually available in packages where the project network diagram correctness is essential for the good use of the package itself (in our case, we used Oracle Pertmaster Risk Expert V8).
• The project network diagram and the critical path were built and kept in the traditional project management tool.
• The critical chain scheduling method - where the schedule model is built on availability of resources and is often defined as a “resource constrained” critical path - was not used. In our case both resources and the assignments of resources to activities were handled in the lean/agile tool.

Performance Measurement

According to the PMBOK® Guide, 5^th ed., “traditional earned value management (EVM) is the methodology that combines scope, schedule, and resource measurements to assess project performance and progress. It is a commonly used method of performance measurement for projects. It integrates the scope baseline with the cost baseline, along with the schedule baseline, to form the performance baseline, which helps the project management team assess and measure project performance and progress. It is a project management technique that requires the formation of an integrated baseline against which performance can be measured for the duration of the project. EVM develops and monitors three key dimensions for each work package and control account: Planned Value, Actual Cost, and Earned Value” and combine them in two indexes: the SPI and the CPI (PMI, 2011).

Traditional Project Management tools allow the project management team to consolidate all this information together and gather a wide set of performance measurements in connection with both standard and customized metrics within the tools: the question arises when traditional tools are used only partially and room is given to emerging tools.

In the case we present here, we decided to store and maintain in the traditional PM tool only the scope baseline and the schedule baseline. Resources were stored in the lean/agile tool and we could not have their costs building up the traditional cost baseline in the traditional tool. We did not want to give up getting our SPI and CPI.

When in general the project management team decides to avoid the estimation of costs of resources using the resources’ costs bottom-up estimation technique, different ways to proceed towards an equivalent calculation of something like the SPI and the CPI can be found, depending on the traditional tool that is adopted.

Alternatives we considered in Microsoft Project are the following:

• Build the cost baseline using fixed costs as attributes of activities and assuming specific trend of accrual (linear, at the beginning, at the end, others). In this case costs are required and PV and SPI are calculated putting together these costs with the schedule baseline
• Avoid the management of costs on activities and work with a weighing system on scheduled activities: this method is probably less accurate but can be used also when costs cannot be handled.

We opted for the second: “Avoid the management of costs on activities and work with a weighing system on scheduled activities.” The following box presents the configuration we designed for the tool.

I.2 – Supporting Scheduling with Non-traditional Tools

Traditional and Agile/Lean Project Management Approach and Tool

“A traditional project management phased approach identifies a sequence of steps to be completed. In the “traditional approach” five developmental components of a project can be distinguished (four stages plus control). Typical development phases of a project are initiation, planning and design, execution and construction, monitoring and controlling systems, completion” (Wysocki, 2012).

Lean/agile project management approaches, based on the principles of human interaction management, are founded on a process view of human collaboration. It is “most typically used in software, website, technology, and creative and marketing industries.” This contrasts sharply with the traditional approach. In the agile software development or flexible product development approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process.

“Some users named traditional project management as being PM 1.0 while the new and improved way of managing projects is PM 2.0. In latter case the accent is put on collaboration by the use of web-based tools in the detriment of more powerful features. By looking at the name PM 2.0 certainly seems better than PM 1.0 but the truth is that there is no clear answer regarding which one is better. It all depends on what type of projects someone is managing. More than probably PM 1.0 will still remain the preferred solution for traditional project management while PM 2.0 will be more suited for agile project management” (Ioan, 2013).

The words we can connect with traditional project management are the following:

• Planning and following a plan
• Monitoring and controlling
• Phases and timelines
• Tasks requiring resources
• Effort to complete tasks
• Assignments

The words we can connect with agile/lean project management are the following:

• Collaboration
• People involved in activities
• Alignment
• Iterations

These words well describe the characteristics that tools inherited from the approaches they were built to serve. So, while traditional project management tools well support the phased traditional approach and the focus on activities and monitoring and controlling processes, agile/lean project management tools well support the work of teams and the processes of knowledge and responsibility sharing.

Lean tools for Project Management: Researchers point of view

Consulting the PMI official site for previous works on “lean project management” and “lean tools,” we discover that there are two main aspects emerging from several studies presented along the last five years:

• Most of the studies interpret the adoption of lean principles in project and program management as a trend toward the elimination of waste (excessive documentation, excessive planning and control, unproductive meetings, avoidable rework, excessive definition of detailed requirements, unproductive multi-tasking).
• Simplifying and standardizing project and program management processes is what most of the studies suggest as a way to obtain value from the emerging theories on lean thinking and management (Gartner, 2013).

In the study “Cool Vendors in Program and Portfolio Management” Gartner recognizes that “projects can fail to deliver their full value if the detailed, day-to-day processes of managing a project's multiple parts are not closely tended. These Cool Vendors offer ways for PPM leaders to make top-down governance more effective and back end processes easier, and, in some cases, more fun” (Gartner, 2013). The study analyses affordable SaaS solutions that enable lean/agile project management and gives managers visibility into work progress.

In his book Lean IT, Steven Bell, highly involved in the activities of the Italian Lean Enterprise Center, dedicates a full chapter to project management. In this chapter, he states that “many project management tools and methods are bloated with waste and add little value. Project managers should learn to utilize Lean principles and tools to reduce wasteful practices, improving project agility and responsiveness” (Bell, 2012).

This short investigation allows us to state that:

• Lean project management can help reduce waste in projects and both simplify and standardize project management processes.
• Under the denomination of emerging lean tools, we can position all those tools that can support and make possible this approach.

Lean tools for task and people management

Among those tools we called emerging lean tools in the previous paragraph we can include plenty of tools which can support program and project management processes. Making an attempt to put in evidence what can distinguish them from traditional tools, the following list of characteristics can be considered:

• Easy to buy and get them ready to use (SaaS modality could be an expression of this characteristic)
• Process oriented more than information and data oriented
• Simple customization of processes
• Cloud-based
• Not full coverage of features, but it's simple to add new ones
• Accessible through browsers
• Import / Export facilities
• Supporting networking among teams and people
• Supporting communications, both professional and more personal ones

Among the emerging lean tools which show these characteristics, some of them have been initially designed to support both managers and developers in their activities of issue and bug tracking and have later covered other project management activities. In theory, the management and tracking of issues involves the engagement of people in activities of several types and can easily be generalized toward the management of activities in projects, where require the sharing of these activities among people working in teams and aiming to gain common goals.

In the case we present here, we were strongly invited to consider JIRA, a tool initially designed as an issue- and bug-tracking tool which is now used to manage some aspects of projects.

Part II – The Integration Idea

“A project is a temporary endeavor undertaken to create a unique product, service, or result” (PMI, 2011). In this definition, the “unique product, service, or result” states that - mainly - a project aims to build “something.” Then, while the word temporary implies that “time” is an important component of a project and must be a point of attention for the project manager, the word endeavor recalls “people doing work” and is the other point of attention for the project manager.

Under the following conditions of the project:

• 4 streams of work (something to be built)
• 3 -year duration (time)
• +200 people involved (people)
• +1000 activities and milestones (work)

Under the following conditions for the performing organization:

• Distributed teams: different premises and locations
• Mixed teams: employees of several large companies
• Good knowledge of traditional project management tool at single professional level
• No intention to adopt an enterprise project management solution
• Need to get performance information on the whole project
• Need to manage small teams inside the whole team

The following was the idea:

Part III – The Case

III1 – Scenario

The case in which we experienced what this paper states is a software project for a large Italian customer in the Telco industry involving more than 200 people and with an expected duration of more than three years. Despite the decisions of keeping average activity duration at not less than 10-20 days and adopting a progressive elaboration approach, one month before kicking off the project we were still dealing with roughly 1,200 Microsoft Project rows.

Proceeding with the assignment of this high number of resources to these numerous tasks was perceived as too risky, especially considering our future goals of tracking activities more than planning. We wanted to consider the possibility to “simplify” the PMIS in general and the Schedule Model for our project.

In the following section we are going to describe some crucial aspects of the built solution:

a)   The transition from Microsoft Project Activities to JIRA tasks and sub-tasks definition

b)   People management in JIRA

c)   Sub-task planning in JIRA and assignment of sub-tasks to people

d)   Progress acquisition (Physical % Complete)

e)   Timesheets (Actual Cost)

f)   Feeding Microsoft Project back with gathered information

III.2 – Some aspects of the solution

Importing Microsoft Project Activities in JIRA

JIRA allows us to import Microsoft Project Activities in a structured format, mapping fields and field values during the import process. We are able to export Microsoft Project Activity as a new task on a specific JIRA Project with the following main data:

• Summary
• Reporter (PM/ PMO)
• Assignee/owner (PM/Team Leader)
• Baseline estimated effort
• Baseline elapsed duration
• Estimated effort
• Elapsed duration

The internal ID returned by JIRA after the creation of the task is brought back to Microsoft Project through a process of synchronization: since then the Microsoft Project Activity is linked with the JIRA task through this ID. Every lowest-level Microsoft Project Activity is put in a one-to-one correspondence with a JIRA task. During the synchronization the owner of the lowest-level Microsoft Project Activity – kept in a customized field of Microsoft Project – is aligned with the owner of the JIRA task. The owner of the JIRA task is called Team Leader.

Outcomes: We have the list of JIRA tasks corresponding to the lowest-level Microsoft Project Activities and each JIRA task will be assigned to the appropriate team leader deducted from the MS Project document

People Management in JIRA

To allow project team members to work on JIRA, they must be registered as platform users and identified by a unique username, for example by their e-mail account. It is useful to organize members of real working teams in JIRA groups. Project roles enable you to associate users to specific functions. The configuration of JIRA as a project management agile tool makes available the definition of some standard roles:

• PMO: Project global permissions, Time Tracking and Planning Permissions
• PM: Project Permissions, Time Tracking and Planning Permissions
• Team Leader TL: Owns task and sub-tasks management permissions
• Team Member TM: Owns worklog edit permissions

Outcomes: Each JIRA user must be a member of at least one or more JIRA groups and must have one or more Project roles. According to her/his group and role membership JIRA user will be able to access her/his own JIRA tasks and the specific associated functions. After logging in, JIRA user may update her/his profile and complete it with a photo, her/his skills, and her/his previous working experiences in order to share information within the JIRA group.

c) Sub-task Planning in JIRA and Assignment of Sub-Tasks to People

After importing in JIRA the Microsoft Project Activities, the owner of both the lower-level Microsoft Project Activity and the JIRA task receives an e-mail notification from JIRA. Then the Team Leader - the owner of the JIRA task – is required to break up the parent JIRA task into a number of smaller sub-tasks that can be assigned to team members of her/his JIRA group.

For each sub-task the Team leader does the following:

• Specifies the work to be done in the appropriate description field of the sub-task
• Estimates/changes the effort to resolve the sub-task
• Estimates/changes the elapsed time of the sub-task
• Assigns an owner to the sub-task chosen among resources of her/his team
• Assigns to the sub-task a set of co-workers (work-assignee)

The Effort estimated is indicated in JIRA as the Original Estimate or Esteem: the sum of the esteems of all the sub-tasks corresponds to the baseline work of the parent task (the baseline work of the Microsoft Project Activity).

Elapsed time is defined in terms of planned start and planned end: the interval obtained by overlapping the elapsed time of all the sub-tasks of a parent JIRA task must be contained in the elapsed time of the parent JIRA task.

Outcomes: Team Leader can track in real time in JIRA the status of her/his own tasks and sub-tasks by mean of a customizable dashboard. In this way Team members involved in doing work and resolving issues, better understand which part of the process they are responsible for.

Percent progress acquisition

JIRA Task workflow is the following:

• the JIRA task is created in open state;
• Team Leader, after partitioning the parent JIRA task into sub-tasks and sub-tasks allocation, starts the task progress, and enables the calculation and reporting of the progress;
• Tasks and their sub-tasks, can be suspended to allow Team Leader rescheduling of estimated effort and elapsed duration;
• When the re-planning process is complete, the task is resumed; and
• JIRA Task will be closed when work is complete

Sub-tasks workflow is the following:

• Sub-task is initially created in open state;
• The “WorkOn” action allows the owner to declare the task start-up, and enables the calculation and reporting of the progress; and
• Task will be closed when work is complete.

Team Members have a dashboard in JIRA reporting the to-do list of all their sub-tasks sorted by priority. The resource, either the owner or the co-worker, takes in charge one of her/his sub-tasks and periodically logs the % of work done and the time spent; Time Spent or Logged is subtracted from the Original Estimate and the resulting value is automatically presented in the Remaining Estimate field.

Aggregate time-spent of all the sub-tasks of a parent JIRA task will be automatically propagated to the parent task and the Remaining estimate of main task automatically updated. In this way the Team Leader and the PM can monitor in real time the effort spent on JIRA tasks. When all the sub-tasks of a parent JIRA task are completed, the Team Leader sets the task state to Closed and the activity completion is notified.

Outcomes: Team Leader and PM can monitor and manage in real time the progress of work of their teams.

Figure 1 – JIRA task and sub-tasks with progress

e) Timesheet Reports

PMO, PM and Team Leaders use the JIRA timesheet and the report view to get a quick overview of project status, and a useful breakdown of all the work to be done.

In our project, we used the User TimeSheet report to display a summary of worked hours for each user or group, during a specified period. TimeSheet Report module has extensive configuration options that we used. We customized filters and obtained our data of interest in Excel format and automatically sent them by email to the owner on a regular basis. We added as a custom field the cost of each resource in order to monitor costs in Timesheet too.

Feeding Microsoft Project Back with Gathered Information

Finally we update back Microsoft Project document with data gathered by JIRA tasks and sub-tasks.

In our case, we set custom synchronization mapping to define the way data are synchronized between JIRA and Microsoft Project. The adopted synchronization rules allow us to export from JIRA into Microsoft Project the total spent effort on a JIRA task - as sum of the spent effort on all its sub-tasks - and the percentage of work done. The adopted synchronization rules also allow us to export from JIRA into Microsoft Project the rescheduled estimated effort and elapsed duration input by the Team Leaders/PM in JIRA.

Figure 2 – The synchronization process

Conclusion

Several approaches to the management of projects are possible: traditional approaches on one side and emerging lean and agile approaches on the other. We cannot state whether one approach is better than another: in fact, all of these approaches have proven their validity in certain conditions. In parallel, project management tools of any kind are emerging and evolving to support these various approaches.

This paper states the possibility of managing project scope and time with a traditional approach, and people and assignments with a more lean and collaborative approach. A real case sustains the theory, shows the form of integration adopted between the two tools, and demonstrates the possibility of synergy between traditional tools and emerging lean tools.

The chosen type of integration offers the benefits of adopting a traditional tool (baseline, WBS, network, and performance indicators) and the advantages of gaining the commitment of people through a more collaborative and lean tool.