Why Is Project Monitoring Very Crucial?

Why Is Project Monitoring Very Crucial?

The intended audience for this article includes people who're associated with project management and want to know about the monitoring process in Agile projects. The objective is to explain the 
importance of monitoring projects and monitoring parameters in Agile. The article is ideally 
recommended for start-up companies, project managers, CXOs and decision makers of
software development companies new to Agile and planning to implement Agile in their work flow.

Many times, complex or long-term projects exceed their budget, or deadlines, or even both, or fail due to some reason or the other. For investors and clients, the ROI is the main point of concern. If break-even points are not achieved early in the project it often leads to financially stressed conditions which tend to force management to undertake drastic steps to curb additional expenditure, or simply stop the project if additional funds are not available to sustain it. One of the commonest factors which lead to non-productive projects is the inability of the team to deliver project value at regular intervals of time. Rather than indulging in post-project failure discussions to retrospect the causes of a failed project, effective monitoring of projects can help teams and management to streamline ongoing projects and make them successful.

Why should projects be monitored?

To monitor a project is to, routinely gather information pertaining to all aspects of the project, observe and record all activities occurring in it. Monitoring involves a systematic and purposeful observation of all ongoing processes in the project. It also includes giving meaningful feedback to the investors and project owners regarding the project status and how the milestones are likely to be achieved over time so informed decisions can be made by them.

Monitoring does not involve just staring at a computer monitor spewing out data from analytics tools and generating reports for the management and team members. The project manager or the process-in-charge needs to understand the metrics and forecast where the project is heading in accordance with the efforts put in by the team and how well the team is performing at the moment. Moreover, other constraints such as budget availability, short staffing, project deadlines and other issues popping up in day-to-day activities also need to be considered as to how they’re likely to affect the success and sustenance of the ongoing project.

Monitoring provides information as to what the status of a particular program, project or policy is at any moment, or is going to be over time, and how well the functioning of various processes in the project, including the resources allotted for it, relates to targets and deliverables. Its focus should also be on optimum utilization of the resources made available for the project. The objective is to track the gap between what was originally planned and what is actually happening now.

Therefore, the primary reason why projects should be monitored is to:

  • Get sound visibility into project execution.
  • Determine what actions need to be taken to ascertain those project objectives and goals are successfully met.
  • How project goals relate to team efforts, delivery schedules and quality of deliverables.
  • Allow the team to educate and learn for itself from its past experiences and improve its productivity levels.
  • Make the team accountable for the work it carries out by evaluating the performance metrics.
  • Justify the capital invested by the stakeholders and investors.

What to monitor?

The nature of the project, its goals and objectives, and its deliverables primarily indicate what parameters should be ideally monitored and in what manner. It can be difficult to generalize the “what” aspect since it may differ from project to project. Generally, the key performance indicators (KPIs) used for monitoring the progress levels in a project are set up collectively by the client and project manager based upon their project related needs and deliverables. Some of the important aspects to monitor for a project can be:

What to monitor?

Objectives and needs of the client

Is the client’s project vision fulfilled and are the project’s milestones successfully met?

The efficiency level of the team

Is the team working as per the development plan and are enough efforts put in to meet the deadlines?

Collaboration and communication levels

Is the team working together in a harmonious manner and pursuing the goals collectively with a single focus?

Business value and work monetization

Is the work delivered by the team monetizable?

Risk mitigation

What are the risks involved in the project? Can they be identified in time? Can they be resolved?

Levels of monitoring

A project should be ideally monitored at three main levels to get a clear insight regarding its current status so corrective measures can be taken well in time.

1. Activity level monitoring

It is done to ensure that each activity defined in the project schedule is carried out in a proper manner and within the time box allotted for it. It can be done by holding daily meetings with the team, or alternately the project manager can check the status of all tasks scheduled to be carried out for the day. Typically, the daily tasks to be carried out by team members are listed on paper and their completion status is checked at the end of the day to identify any pending work remaining on that particular day. This level of monitoring is basic to all project management processes since it makes the team accountable for the work assigned to it. It is to ascertain that the project proceeds as per plan and delivery deadlines can be met successfully.

2. Project status reporting

Usually generated once a week, project status reports often contain a summary of all tasks completed successfully by the team in the week gone by against the actual activities planned for that week. The idea is to identify how much of work is completed in the project, how much of it is still pending, and whether the deliverables can be produced by the team considering its current rate of delivering work. It also helps to identify the causes of delays logged by the team and pinpoint any pitfalls hampering team productivity.

3. Milestone analysis

An analysis is done every few weeks to make sure whether milestones supporting the project vision are, or can be, achieved within the time duration allotted for its completion, and to find out how much of efforts are actually put in by the entire team over time to achieve the proposed milestones. When plotted on a graph, it helps to identify any deviations occurring in the proposed “line” of project completion versus time. If the deviation is severe or more and objectives are not met with time, project managers need to identify and understand the root causes and undertake corrective measures in time to correct the deviation so milestone deadlines can be met successfully.

Monitoring Agile projects

The success of an Agile project is not dependent only upon whether the process is properly implemented in the project or not. Three factors count – monitoring the progress, monitoring how Agile principles are followed by the team, monitoring how the business value is acquired.

1. Monitoring the project progress

There are three main metrics for monitoring the project’s progress.

Monitoring the project progress

•  Sprint Burndown

An Agile team organizes its work in time-boxed durations called “sprints” which range from two weeks to a maximum of one month. The entire software is developed by the development team in these sprints. The sprint burndown metric tracks how the team has completed work throughout the sprint.

•  Release Burndown

While the sprint burndown metric focuses upon work completion at the iteration sprint level, the release burndown metric takes into consideration the status of various sprints covering the entire project. In Agile the product is released in stages – in the form of individual releases – by developing a set of features for each release. Business value in the project is acquired by releasing the product features in the market in the form of planned releases or versions ranging over a specific duration of time. The release burndown metric is useful for determining how much work is still left in the project and when the business value in the project can be realized over time. It is also useful for identifying any “scope creep” i.e. if more requirements are added to the original project and the scope of the project has increased significantly. To avoid scope creep from affecting the value of deliverables, the product owner always suggests important stories having high business values to the team for development purposes in the sprint.

•  Velocity

It is the amount of work, in the form of user stories that the team completes during a particular sprint. It is an important metric for forecasting how much work the team can handle in a sprint and the product owner uses it to decide how many stories should be selected for the sprint. It is a metric tracking the total work completed in the sprint versus sprint days. As the team executes sprints over time and takes up more work in the sprints, the metric improves and becomes more consistent over time.

2. Monitoring Agile implementation

In Scrum, an Agile based process, a special role is dedicated for overseeing the implementation of Agile principles in the project. The Scrum Master functions as a facilitator and ensures that the team follows the process in a proper manner. He/she ensures that the team does not face any impediments while working and also overlooks the various events or ceremonies involved in the process.

3. Monitoring the business value

A major difference between tradition project management methods and Agile is that the former focuses on delivering software fulfilling just client-based requirements while Agile believes in maximizing the ROI through continuous delivery of shippable software and reducing waste. Re-planning of the deliverables can be easily done using Agile. Therefore, Agile measures outcomes over outputs and measures the Earned Business Value “EBV” metric. The metric also takes into consideration how efficient and effective the team is performing while it delivers the business value in the project.

The business value can be calculated as:

EBV = Earned Business Value = The total of all Business Value Indices for completed stories =?BVI(story) for all the stories completed in the first n sprints.

Types of issues faced during Agile implementation and how to resolve them

Based upon the open-mindedness of the team, its cultural and education levels, the degree of professionalism and the willingness to accept change management, development teams may find it moderately or very hard to accept Agile. Some common issues are mentioned herein.

Agile implementation issues

There can be many types of issues related to Agile implementation. However, a couple of common ones are discussed here.

1. Resisting change

This can be a very common issue in Agile implementation. Teams following traditional development methods are very much used in the staged processes and feel comfortable delivering work that is tested for bugs and regression in the next process stage. Developers focus only on coding aspects and don’t have to bother about optimizing the code or verifying their work whether it aligns with the project requirements or not. It can prove to be very difficult for them to adjust to the product incremental method typical to Agile processes in which the development team is not only accountable for its work but is also required to focus upon testing the code and ascertaining that the work delivered by it fulfills the product vision and end-user requirements.

Moreover, each team member is required to own the project and hold himself or herself accountable for his or her work. In addition, another aspect is that the team has to estimate how much work it is capable of accomplishing in a sprint and justify the reasons why it can only take up limited or less work for development at a time. Unlike in staged processes, Agile teams have to commit how much time it will take to deliver work and live up to that commitment.

The third aspect is that Agile promotes a working atmosphere in which each member in the team has to think like an entrepreneur and find innovative ways to work smartly and make active efforts to accomplish work in a shorter span of time. This can go hard with the mindset of teams used to traditional methods in which they are not required to think in any other manner except as developers or designers.

Development teams are generally reticent about change management and try to actively or passively oppose change when it is required to be introduced to improve the quality and quantity of deliverables. With Agile, the resentment is even more since the team members have to undergo a drastic mindset change and learn about the new process.


The management should try to introduce Agile after explaining the benefits of the new process and what the organization and the team stand to gain from Agile experience in the long run. It is important to convey the message that change is inevitable and Agile is to be implemented irrespective of whether any team member decides to resign or discontinue the process. Moreover, the management should also try to motivate the team and create an open environment supporting transparency and freedom where the team can frankly discuss its apprehensions and find a way to proceed with the change.

2. Understanding the process

Agile introduces fundamental changes in the way most people following traditional methods work. Teams have to open up their mindsets and think creatively, in an optimistic manner, and welcome the change. Moreover, Agile processes like Scrum have ceremonies and artifacts which can be totally new concepts for most teams. Developers have to understand the product incremental model and its cycle, what continuous development and continuous integration is developed, and a host of new concepts to reckon with.

  Estimating work

Developers are not very good at estimating work completion and deadlines. Generally, they hate a situation where they’re forced to commit a date or time and rigidly stick to it. This is exactly what Agile demands. You not only have to estimate work but make all efforts to deliver it in time with the required quality.

•  Roles in Scrum

In contrast to traditional or classical methods, Scrum – an Agile process – doesn’t have and doesn’t need any manager, task manager or a team leader. The three roles are:

1. Product Owner

2. Scrum Master

3. Development team

These three roles are coequal. Each role has certain responsibilities. Also, each of these three roles has to fulfill their responsibilities by closely interacting and working together to finish a project successfully. Team members may find it difficult to understand and follow these roles.

•  Meetings and ceremonies

Scrum process includes several types of meetings or “ceremonies”. Agile teams are cross-functional in nature. They take part in the ceremonies and make important decisions. Non – cross-functional teams may find it hard to understand and accept what these ceremonies stand for and might resent taking part in them.


Some managements prefer to introduce Agile slowly in their organizations or employ a hybrid approach in which certain activities are made Agile while others are carried out as before. Experts suggest neither of these methods works in real life scenarios since the teams might just keep on resisting Agile until the management arrives at a conclusion Agile is not worthwhile and the changes should not be implemented. It’s best to transition totally to Agile even if the team find it difficult to do so.

3. Development related issues

Development related issues are highly common with teams starting with Agile practices since they are not much familiar with the product incremental structure of the development process. Agile teams are cross-functional and often developers also perform test cases to check code quality and reliability. At times, teams employ specialized testers and QA professionals to carry out quality tests. Whatever the case, if Agile principles are not followed in a proper manner it directly affects productivity and performance levels.

•  Losing sight of the project goal and deliverables

In Agile, the business value in the project is availed through staged and planned releases. Therefore, the development team needs to focus more upon delivery of value through it work rather than just coding feature requirements. In practice, teams often experience time constraints while meeting sprint deadlines. So over time, they may lose their focus of delivering valuable work and start concentrating fully upon work completion. Teams stop thinking about what the product vision is and what goals the project needs to achieve to sustain itself. This leads to unfocused work efforts and disorientation – the team keeps on developing features and doing its work because it is supposed to, and not because the project goals and objectives should be achieved. Developers and designers stop being creative in their work. They stop innovating new and better ways of developing features and working functionality. As a result, the velocity metric indicating the total work completed by the team in the sprint stops improving, thus conveying the fact that the team has stopped learning from its past experience and not speeding up work. This is contrary to Agile principles.

Moreover, each team member is required to own the project and hold himself or herself accountable for his or her work. In addition, another aspect is that the team has to estimate how much work it is capable of accomplishing in a sprint and justify the reasons why it can only take up limited or less work for development at a time. Unlike in staged processes, Agile teams have to commit how much time it will take to deliver work and live up to that commitment.


The Scrum Master and project leads should constantly try to motivate the team members and hold healthy discussions so ideas can be exchanged regarding how the development process can be streamlined, made more easy and less time to consume using online tools and development aids if possible. Retrospection activities should be encouraged. Teams should be made more accountable by holding short meetings at regular intervals of time (all though this is not recommended by Agile – the principles state the team should take work ownership but in practice, the team members actually don’t which is the main problem) to obtain feedback regarding the work status. The management should also step in and try to create a healthy and conducive working environment to reduce the stress levels.

•  Not delivering feature functionality as explained and anticipated

The client expects a particular feature to work in a particular manner whenever he/she requests its development. Each task or feature requirement in Agile – known as a user story – can be explained in terms of what criteria needs to be fulfilled for it to be considered as properly developed and shippable. It helps to make the feature valuable and monetizable after its development. The team starts ignoring this criterion due to some of the other reason or loses its sight while building it. As a result, a feature is developed that is not in tune with what the client expects or needs.


More stress should be given for the team to focus upon the acceptance criteria and the definition of done (DoD) which determines the value of the feature and its importance. Developers should be reminded again and again to create work in tune with these criterions and ensure they test the feature after they develop it.

•  Lack of participation in retrospection activities

Agile stresses very heavily upon the “inspect” and “adapt” principles which form the core of all Agile processes. The team has to learn constantly from its past mistakes and ensure they’ve not repeated again in the future. Also, new and better ways of doing work should be discovered to increase productivity levels and deliver more valuable work. All this is made possible through the retrospection activities in Agile. In Scrum, a special ceremony known as the sprint retrospective meeting is held at the end of each sprint to support this principle. The team stops participating in these activities as a result of which further improvement in work in not availed and the velocity index stops improving. Further growth stops in the project.


Retrospection activities should be made mandatory and team members encouraged to participate in them. If required, team members can be told to discuss new ways of improvement and prepare a list or a plan stating what new activities they propose to do with proper call-to-actions.

•  Ineffective testing procedures

Testing procedures – especially unit tests – form an integral part of the development process and should be carried out preferably in the sprint itself when the particular feature is being developed. Testing ensures that the definition-of-done is properly fulfilled by the team, there are no bugs in the feature and that the feature is valuable to end users. Many times teams don’t carry out these tests since they may be time-to consume, or the team lacks the necessary resources or skill sets to perform them. The work delivered in such cases may contain bugs and lead to regression. The project owners may incur technical debt in the future.


Testing activities should be made mandatory and teams should start considering testing procedures as an integral part of the development process. They should be accounted for while the team estimates work during sprint planning sessions held just before a newsprint is planned.

•  Miscommunication between developers and testers

Effective communications are required for doing quality work. When team members discuss things and exchange ideas, thoughts become clear, and the entire team comes to know about the nature of deliverables and how they should be built. In Agile, testing should be a part of the development process and testers should work closely with developers to resolve test related issues and problems. When testers stop communicating with developers for test issues, or developers stop responding to testing queries, it leads to a situation where partially or improperly tested features are released in the market which can reduce the project value in the long run.


The product owner or the project lead should motivate team members to collaborate and exchange ideas. At the same time, developers and testers should be made more accountable regarding the quality of deliverables – especially fulfillment of the DoD – to ensure only fully tested and valuable features are developed at all times.

•  Development work held up because of code and functionality dependencies

Big or complex project development can have a lot of dependencies as far as code functionalities go. Often a piece of code created by one developer functions as a source of input for the task to be developed by another developer. In such cases, the second developer has to wait for the first developer to complete his or her work and create the particular functionality before the later one can start with his or her work. During the second half of the sprint planning session when the team members are selecting and taking up their development tasks, they should also discuss code dependency issues and organize their work accordingly. When team members don’t analyze their tasks and don’t discuss the dependencies, it leads to a situation where one developer is loaded with urgent work while the other one has to wait for the first one to complete. Time is wasted and productivity at the team level is greatly reduced. It decreases team velocity.


The developers and team members should work more closely and analyze dependencies before they take up their tasks. If dependencies still exist, each developer should plan his or her work with regards to the work to be carried out by the developer who’s going to be affected by the particular dependency.

4. Communication and collaboration related issues

Communication levels play a vital role in a project’s success. Right from project inception to delivering goals and objectives, the team relies upon timely and effective communication to develop product features, share ideas and resolve technical issues. With remote or distributed teams working in the project, communication between project managers and teams can often prove to be difficult owing to different time zones and cultural differences. With in-house teams, effective communication lays the foundation of a shared product vision and the harmonious working environment in which the team can make informed decisions by discussing, analyzing and working together.

  • Communication

  • The sixth principle in the Agile Manifesto states: “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.”In Agile, it is crucial to have effective communications between developers and the client, end users, and the stakeholders. The team develops software as per the product vision explained by the client. In turn, the client verifies work delivered by the team at the end of each sprint. Team members need to communicate with each other to resolve development issues. At every stage communication is vital and when it stops, it could raise some issues.
      • Some of the causes could be:
        • Miscommunication of requirements
        • Different time zones
        • Failure to focus and listen properly
        • Culture differences
        • Attitude and ego related issues
        • Gender bias
        • Inadequate knowledge
  • Collaboration

  • Collaboration amongst team members can be challenging since developers are used to their individual methods for creating code and working functionality, and may find it very hard to follow someone else’s coding methods. Agile processes favor continuous development. It is common for the team to use GitHub or Git to share, update and version the code before final changes are uploaded for deployment. It is recommended the team follows certain coding standards to make the code readable to others. To work effectively, the team needs to constantly collaborate and share ideas and suggestions to make things work.
      • Some of the common issues faced can be:
        • Priority conflicts
        • Insufficient alignment amongst team members
        • Limited automated software development processes – lack of Continuous Delivery
        • Coordination challenges
        • Unpredictable software delivery
        • No visibility over status, progress, and results

Share and Enjoy !

0 0 0