Challenges of Managing Software Projects in a Distributed Tool Setup
It's hard to monitor software project metrics when the tools are distributed.
Join the DZone community and get the full member experience.Join For Free
Managing an end-to-end application and brining process, teams, and tools together in a multi-tool, complex production environment has always been a painful, yet crucial job in any organization. This effort involves risks of miscommunication and delivery uncertainties throughout a project’s lifecycle. The lack of traceability links between tool artifacts can make the process of impact checking and decision making extremely difficult. Too much of manual involvement also makes the entire process of reporting error-prone.
Information Gap Causes Decision Dilemma
In a software organization, a project manager needs to monitor several things at a time, such as estimated cost per feature development, resource allocation, project priorities, and time allocation for requirements analysis and design. This is in addition to monitoring effort estimation in development and testing jobs, controlling productivity and quality improvement of internal teams, and managing frequent changes in product specifications due to changing requirements. The manager also needs to identify delivery bottlenecks, review every stage of development processes and adopt best practices to ensure quality and stability of the current release.
Most of the time, in a disparate tool environment, managers do not get automated and real-time consolidated reports explaining what, when, why, where, and how of a development activity that can be readily used for decision-making. There is a lack of traceability between tool-specific information and unavailability of the change history of the tool objects. This leads to a plenty of manual interactions, making the overall process error-prone.
Team and Tool Silos – The Fundamental Barrier for Managers
In a typical software project, requirements are captured and analyzed numerous times, tests are performed in multiple locations by varied users, and change requests are analyzed and implemented several times even after delivery. However, in most of the cases in a disjoint tools environment, all these actions happen without anyone’s in-depth knowledge of what is in a particular build, and whether it includes all the latest customer requirements. Business analysts do not know which customer requirements are designed, which ones are coded, and which are tested. Developers do not know about the detailed customer discussion and business perspective for which they are developing the solution. Testers do not know which other parts of an application need retesting when they are testing certain fixes for a bug.
Thus, senior management keeps harnessing who is doing what and why, and how each of these actions impacts the end-to-end delivery process. This involves a large amount of analysis and manual hand-offs which are time-consuming, labor-intensive and error-prone. Even a single misjudgment due to a miscommunication may lead to discrepancies in team’s workflow followed by late delivery.
Conflict of Interests – Hindrance for Mangers
Modern software delivery organizations involve multiple teams, including development, project management, customers, and internal and external testing organizations from different locations. Each of these working group leverages a unique set of tools, deploys their own processes and methods that are optimized for their own group. These approaches are not necessarily aligned to the end-to-end process. For example, development and testing groups have their own priorities and responsibilities. The development team keeps user stories and tasks in sync within the team, whereas the testing team prioritizes on resolving defects and issues.
Though organizations spend in millions for their individual software development teams and tools to manage software requirements, the project and portfolio, software design, development, testing, deployment, and operations, it is rare that the teams, tools, and processes are in collaboration with each other through a centralized system. The results are the lack of transparency in process flows, unavailability of cross-tool metrics and insufficient overall project visibility.
Governance Needs Integration between Systems
The term Application Lifecycle Management (ALM) indicates that management is an integral part of application development. In the white paper entitled "What is Application Lifecycle Management”, David Chappell, the principal of Chappell & Associates describes ALM as being composed of three distinct areas – governance, development, and operations – each with a series of demarcated events. Governance, unlike the other two phases, encompasses all project management and decision-making steps and extends over the entire lifecycle of an application, until the application has no business value and is removed from the service. All these three broad phases need to be integrated horizontally as well as vertically so that the project management office gets a single chain of information cutting across tool and team boundaries.
Once the development process starts, the governance phase includes project portfolio management and then, as the application gets ready, it continues through the application portfolio management steps. Both of these steps are highly sensitive for decision-makers. This signifies how important it is for senior managers to have a 360-degree visibility of the entire project, from its inception to development to delivery and maintenance. They need to be aware of the details of running project items all the time and do regular audits for compliance and performance improvement.
Tool Specific Reporting is Not Enough
During governance, senior managers usually browse several tools, aggregate a pool of data from internal teams, consolidate them based on priority and relevance, and then produce a multitude of reports that are meaningful and futuristic to both internal teams and top management. However, this data mining requires a multitude of manual handholding which is time-consuming and error-prone. Integrating reports from multiple tools is also not a viable option because each tool gives a certain set of data that is only a piece of the whole puzzle. Integrated reporting is feasible only with a centralized reporting system, where all tools are tightly knit together through a common data repository.
The One-Stop-Solution for Many Organizational Needs
Integrated ALM is a totally synchronized environment which ties teams, tools, and processes together. An integrated development environment allows different teams, managers and senior management of an organization to remain updated in a real-time manner on the progress of a release. It ensures effective collaboration among teams followed by better project visibility and transparency, enabling faster time-to-market with good quality product.
We will learn more about the organizational benefits of implementing an integrated or Synchronized ALM setup in the second part of this article.
Today’s managers have realized that project monitoring is not possible without a centralized visibility into the application development tools. This requires an automated metrics collection system that is integrated across the lifecycle chain. An integration framework built around best-of-breed tools, gives managers a ready-to-use solution that delivers relevant, objective, dynamic, and granular metrics to help them make informed decisions about cost, quality and time of delivery.
Opinions expressed by DZone contributors are their own.