Mastering Risk Management in Project Leadership: A Practical Guide for Project Managers

In any comprehensive course on project management, one theme repeatedly emerges as central to project success: effective risk management. It's not simply a best practice—it is a core discipline that every competent project or program manager must master. Many seasoned professionals even argue that once a project is underway, risk management becomes the most critical and continuous area of focus.

Despite its importance, risk management often gets sidelined in the hustle of project execution. A large part of this is due to its subjective nature—risk isn’t always visible or easily quantifiable. However, subjective does not mean intangible. With the right processes and mindset, project managers can consistently identify, assess, and mitigate risks in a structured way.

Based on my own experience leading and mentoring project teams, I believe that there are two fundamental pillars of effective risk management:

1. Recognizing Common, Known Risk Areas

Every organization that operates at a mature level has a set of known risk factors that tend to repeat across different projects. These risks are often related to:

• Schedule delays

• Team attrition or sudden personnel transfers

• Feature creep or uncontrolled scope changes

• Budget constraints

• Vendor reliability

These types of risks are considered "known knowns"—they're the usual suspects. A proactive project manager should have access to historical data or a shared risk register that documents past risks, their impact, and how they were mitigated.

A best practice here is to regularly review and update this organizational risk repository. This enables the team to stay ahead of predictable problems. For instance, if historical data shows a 20% increase in scope-related delays during Q4 due to end-of-year product push, your project schedule should already account for this.

Project managers must periodically assess these known risk areas throughout the lifecycle of the project. Risk logs should be living documents, not static checklists filed away after kickoff. If a known risk manifests because it was ignored or underestimated, the responsibility lies squarely with the project manager.

However, it is not uncommon for even experienced professionals to get caught up in daily operations, firefighting deliverables, and managing stakeholders. In doing so, they lose the mental bandwidth required to continuously review and assess known risk factors.

Avoiding this pitfall means embedding risk review into your routine processes. This could be as simple as adding a five-minute discussion point in weekly status meetings or setting aside 30 minutes each week to review the risk log and evaluate current triggers.

2. Navigating the Unknown: Identifying Emerging Risks

The second category of risk is much harder to pin down: the unknowns. These are risks that aren’t documented in any database. They haven’t occurred before, or they manifest in new, unpredictable ways. But make no mistake—they're just as real.

Consider a real-world example: your competitor suddenly launches a disruptive update to their product, forcing your team to recalibrate features that were in development. This, in turn, impacts timelines, resource allocations, internal communications, and possibly even the entire release strategy.

While you can’t predict every market move, you can put systems in place to surface emerging risks early. This involves:

• Regular sync-ups with cross-functional leads and product managers

• Encouraging a culture of transparency and early escalation

• Tracking subtle signals from the field, such as customer support feedback, developer bottlenecks, or sales sentiment shifts

• Reviewing change requests not just for technical feasibility but for strategic alignment

The key here is visibility. You can only mitigate what you can see, and the earlier the better. Every change request, every team concern, and every product pivot should be reviewed with a "what could go wrong?" lens.

To manage emerging risks effectively, project managers should use a hybrid approach combining traditional tools like a RAID log (Risks, Assumptions, Issues, and Dependencies) with more adaptive practices like lightweight agile retrospectives and real-time issue tracking platforms.

Building a Culture of Risk Ownership

Project risk management should never be a one-person responsibility. An effective project manager builds a risk-aware culture across the team. This means:

• Encouraging team members to report potential risks without fear

• Rewarding early detection of issues, even if they don’t materialize

• Assigning clear ownership of risk items

• Embedding risk impact discussions into change request reviews

By normalizing risk conversations, you reduce the stigma around raising concerns. This ensures that your team becomes an early warning system rather than a passive set of executors.

Integrating Risk Management into Daily Practice

Effective risk management doesn’t happen in isolation. It must be integrated into everyday project management activities. Here are a few best practices:

• Risk Workshops: Conduct short risk brainstorming sessions at the start of each major phase.

• Risk Review Cadence: Build a rhythm of reviewing the risk register weekly or biweekly.

• Trigger-Based Tracking: Define what "early indicators" might suggest a risk is developing.

• Risk Scoring: Use a simple matrix to score risks based on probability and impact.

• Scenario Planning: Consider “what-if” exercises to prepare the team for critical disruptions.

Over time, these habits not only reduce the number of surprises but also equip your team to respond more calmly and effectively when things do go sideways.

Measuring Risk Management Success

One of the challenges in risk management is measuring its effectiveness. Unlike deliverables or velocity, risk mitigation doesn’t always have immediate, visible results. Still, you can track:

• Number of risks logged and actively monitored

• Percentage of risks mitigated before impact

• Stakeholder satisfaction during crisis periods

• Response time to emerging issues

You can also gather qualitative feedback post-project to evaluate how prepared the team felt and whether contingency plans were effective.

Common Pitfalls to Avoid

1. Treating Risk Management as a Phase: Risk isn’t just for kickoff. It’s a continuous, adaptive process.

2. Ignoring Soft Signals: Risks often start as subtle concerns before becoming showstoppers.

3. Overengineering the Process: Keep tools and logs simple. Focus on actionability, not bureaucracy.

4. Shifting Responsibility: Everyone owns risk, but the project manager is accountable for visibility and response.

5. Not Updating the Plan: A risk register is a live document. If your plan never changes, you're likely missing real-time shifts.

Final Thoughts: Risk Is Inevitable, Unpreparedness Is Not

Every project, regardless of size or complexity, will encounter risks. The difference between successful and failed initiatives often lies in how well those risks are understood, communicated, and managed.

Project managers must resist the temptation to view risk management as optional or peripheral. It is, in fact, one of the most strategic capabilities you can develop as a leader. Done well, it not only protects timelines and budgets—it builds trust, boosts team morale, and enhances your reputation as a calm, reliable, and forward-thinking project professional.

So, the next time you lead a project, remember: risk isn’t the enemy. It’s a signpost. And how you respond to it will determine not just the outcome of your current initiative but the trajectory of your career.

You may not be able to follow everything listed above :-), but you still should evaluate what works best for you. And if you are doing something else that works well for you, please add below.

---

The Communication Loop: Why Keeping Project Managers Informed is Key to Project Success

In the fast-paced world of project delivery, especially within the intricate web of software development and IT, effective communication isn't just a nicety; it's the lifeblood of success. Recently, a seemingly minor oversight on my part served as a potent reminder of this fundamental truth, highlighting how easily crucial stakeholders can be left out of the loop and the potential ramifications of such an omission. It all started with an email from another Program Manager (PgM). While her official title might have been slightly more junior than mine, we both fulfilled the same vital role within our respective teams – and in the trenches of project execution, it's the role and responsibilities that truly matter, not the hierarchical label.

Her team was responsible for delivering certain modules that our team consumed for a larger project. We had a history of successful collaboration, and the coordination between our teams had generally been smooth. However, with a new request on the table, one of our senior developers initiated a discussion directly with a senior developer from her team. This technical dialogue continued for some time between these two experts, focusing on the nitty-gritty details. Eventually, our developer looped me into the email chain. I reviewed the progress, added my comments regarding schedules, dependencies, and broader project alignment, and proceeded with the discussion. My critical mistake? I didn't take the elementary, yet crucial, step of ensuring the Program Manager from the other team was also included in this evolving conversation.

It was about a week later that she discovered she was out of the loop on discussions concerning features, potential delivery timelines, and work that her team would ultimately be tasked with executing. Understandably, she sent me an email (and I'm sure had a similar conversation with her developer) politely but firmly inquiring why she hadn't been included in these critical discussions about a delivery her team was accountable for. I had no "great answer" for this oversight, other than to acknowledge the mistake and affirm that she absolutely should have been part of the conversation from a much earlier stage.

This incident, though resolved amicably, underscores a tricky yet persistent point in project collaboration: at what stage, and to what extent, should various stakeholders, particularly Program or Project Managers (PMs), be involved in ongoing discussions?

The Shifting Sands of Involvement: Team Dynamics and Established Norms

The dynamics of when a PgM or PM steps into detailed discussions can vary significantly from one team or organization to another. There's no single "right" moment that universally applies.

• Developer-Led with Later PM Engagement: In some highly experienced or autonomous teams, developers might carry technical discussions quite far, hashing out feasibility, initial approaches, and even preliminary estimates amongst themselves. The PgM might only be brought in when concrete scheduling commitments are needed, resource conflicts arise, or formal agreements need to be documented. This often works well when the scope is well-understood by the developers and the project has a history of smooth execution.

• Early and Continuous PM Involvement: In other groups, or for projects with greater complexity, ambiguity, or cross-functional dependencies, the PgM or PM might need to be involved from the very outset of any significant discussion. They might facilitate initial requirement clarifications, ensure alignment with broader program goals from day one, and proactively identify potential roadblocks.

It’s crucial to understand that the point at which a PgM/PM typically enters detailed discussions is not necessarily a reflection of a team's "maturity" or "value system." More often, it's simply a reflection of how the working dynamics and communication protocols of that particular group or interacting groups have become established over time. Sometimes these established norms work efficiently; other times, as my recent experience showed, they can lead to unintended communication gaps.

Why the Program/Project Manager's Involvement is Non-Negotiable (At Some Point)

Regardless of a team's specific dynamics, there is no denying the fact that the Program Manager or Project Manager does need to be involved at a certain stage. Their perspective and responsibilities extend beyond the purely technical, encompassing a range of factors that developers, however skilled, may not have full visibility into or authority over.

Here are just a few compelling reasons why their inclusion is critical:

1. Strategic Alignment and Prioritization:
   A PgM often has a broader view of the overall program or portfolio of projects. They understand the strategic objectives and can ensure that new requests or proposed solutions align with these higher-level goals. At an extreme level, as you rightly pointed out, the team may have been directed by senior management to focus on entirely different critical work, making them unable to cater to a new request, no matter how technically sound. Only the PgM might have this overarching visibility.

2. Resource Management and Conflict Resolution:
   This is a primary responsibility of any PgM/PM.

   • Scheduling Conflicts: A developer on one team might agree to a timeline with a developer on another, unaware that their own team's PgM has already committed those resources to a different, higher-priority task.

   • Resource Conflicts: Is the required expertise available? Are team members already over-allocated? Are there dependencies on shared resources (e.g., testing environments, specialized equipment)? The PgM is typically the one tracking these allocations and is in the best position to identify and resolve such conflicts, often through coordination with other PgMs or managers.

3. Budgetary Oversight:
   Many technical discussions can lead to solutions with varying cost implications (e.g., using a new licensed tool, requiring additional cloud services). The PgM is usually responsible for managing the project budget and needs to be aware of any decisions that could impact it.

4. Dependency Management:
   Software projects rarely exist in a vacuum. There are often dependencies on other teams, third-party vendors, or infrastructure changes. The PgM tracks these external dependencies and ensures they are managed to avoid bottlenecks.

5. Risk Management:
   Early discussions might reveal potential technical risks, scope uncertainties, or external dependencies. A PgM is trained to identify, assess, and plan mitigation strategies for such risks. Keeping them informed allows for proactive risk management.

6. Stakeholder Communication (Broader Audience):
   While developers might communicate effectively with their technical counterparts, the PgM is often responsible for communicating progress, issues, and decisions to a wider range of stakeholders, including non-technical business users, senior management, or even clients. They need to be party to the core discussions to fulfill this role accurately.

7. Scope Management:
   As technical discussions evolve, there's always a risk of "scope creep" – where well-intentioned additions or changes gradually expand the project beyond its original objectives. The PgM plays a crucial role in managing scope, ensuring that changes are evaluated, approved, and their impact on schedule and resources is understood.

8. Tracking Agreements and Action Items:
   As highlighted, once discussions reach a certain stage, especially if they involve multiple people or teams, there's a clear need for regular interactions and for somebody to meticulously track the agreements made and the action items arising from these meetings or discussions. This formal tracking is a classic PgM/PM responsibility, ensuring accountability and progress. Without it, valuable decisions can be lost, and momentum can stall.

The "When" and "How": Best Practices for Inclusive Communication

So, how do we avoid the "missed CC" scenario and ensure the right people are in the loop at the right time?

• Err on the Side of Inclusion (Initially): It is almost always better to include the relevant Program/Project Manager (from all involved teams) in initial discussions or as soon as a request starts to solidify beyond a very preliminary technical query. As suggested, "it is best if the person gets included and they then can figure out their level of involvement at different stages of the discussion." A good PgM will appreciate being informed and can choose to monitor passively, delegate follow-up on certain threads, or step in more actively as needed. They can always opt-out of threads that become too granular for their immediate attention, but they cannot opt-in if they are unaware.

• Establish Clear Communication Protocols: For recurring inter-team collaborations, it's beneficial to have agreed-upon communication protocols. This might include:

  • Always CC'ing respective PgMs/PMs on initial requests or significant updates.

  • Defining clear points of contact for different types of queries.

  • Establishing regular inter-team sync-up meetings led or attended by the PgMs.

• Developer Responsibility: Encourage developers to proactively include their PgM/PM when discussions start to involve timelines, resource commitments, scope changes, or potential impacts on other projects. It’s not about micromanagement, but about shared awareness.

• Use Centralized Communication Tools: Utilizing project management software (like Jira, Asana, Trello) or shared communication channels (like Slack, Microsoft Teams dedicated channels) can help keep discussions visible to a wider relevant audience, reducing the chances of someone being inadvertently excluded from an email thread.

• The "No Surprises" Rule: A good guiding principle for any team member is to ensure their PgM/PM is never surprised by a major development, commitment, or roadblock. This fosters trust and allows the PgM to manage expectations effectively with other stakeholders.

• Regular Check-ins, Even for Technical Threads: Even if a technical discussion is ongoing primarily between developers, a brief summary update to the PgMs at key junctures can be invaluable.

My Learning: The Value of the Elementary Step

My oversight in not including my counterpart PgM was a simple lapse, an "elementary step" missed in the flow of a busy project. Yet, it highlighted a critical truth: the project's health depends on these connections. Her being out of the loop could have led to misaligned expectations for her team, potential scheduling conflicts that would only surface later, or her team being blindsided by commitments made without their managerial oversight. The potential "boo-boo" mentioned, and the subsequent "uncomfortable words with the boss," are very real consequences that can arise from such communication failures, eroding trust and efficiency.

Conclusion: Weaving a Stronger Web of Collaboration

In the complex tapestry of software development and project management, ensuring that key stakeholders – particularly Program and Project Managers – are kept consistently in the communication loop is not just good manners; it's a fundamental prerequisite for success. While the exact timing and depth of their involvement may vary based on team dynamics and project specifics, the principle of proactive inclusion should always be favored.

The Program Manager acts as a vital hub, connecting technical execution with strategic goals, resource realities, and stakeholder expectations. By ensuring they are informed, we empower them to navigate conflicts, manage risks, and steer the project effectively. My recent experience served as a valuable, if slightly humbling, reminder that even the most seasoned professionals can benefit from revisiting these elementary principles of communication. It's through these conscious acts of inclusion that we build stronger teams, foster more transparent collaborations, and ultimately, deliver better outcomes for everyone involved.

Further References & Learning:

Books on Project Management, Communication, and Team Collaboration (Available on Amazon and other booksellers):

"A Guide to the Project Management Body of Knowledge (PMBOK® Guide)" by Project Management Institute (Buy book - Affiliate link): The standard reference, with extensive sections on stakeholder management and communication planning.

"The Five Dysfunctions of a Team: A Leadership Fable" by Patrick Lencioni (Buy book - Affiliate link): Highlights the importance of trust and communication in team effectiveness.

"Making Things Happen: Mastering Project Management" by Scott Berkun (Buy book - Affiliate link): A practical and insightful guide to project management, emphasizing communication.

"Agile Project Management with Scrum" by Ken Schwaber (Buy book - Affiliate link): Details communication and roles within the Scrum framework.

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister (Buy book - Affiliate link): Focuses on the human elements of software development, including team dynamics and communication.

YouTube Videos Explaining Project Communication and Stakeholder Management (too many to show here, just search for these topics below):

1. Search "Project Management Communication Plan": Many PMP training channels and project management experts cover this topic.

2. Search "Stakeholder Management in Projects": Understanding who to keep in the loop and why.

3. Search "Effective Communication for Project Managers": Tips and techniques.

4. Search "Agile Communication Practices" or "Scrum Daily Standup Purpose": For insights into communication within Agile teams.

5. Search "Avoiding Common Project Management Mistakes": Communication gaps are often high on these lists.

6. Channels like:

   • Project Management Institute (PMI) Channel: Official talks and resources.

   • Adriana Girdler - Project Management & Leadership Coach: Practical tips for project managers.

   • Praizion (YouTube channel by a PMP trainer): Detailed explanations of PMBOK concepts.

   • Business and leadership channels that discuss effective communication and teamwork.

Project Manager - Keeping the morale of people up

The job of a Project Manager in a software project is a complex one. Technically, the Project Manager is supposed to lead the project in the best possible manner, and try his / her best to understand the issues faced in the project, raise them to the best possible manner in order to resolve it and keep as much as on schedule as possible.
In reality, the Project Manager is the person who is the last resort person. He or she is the one who needs to understand issues which have rose in terms of complexity and drive /delegate the process of resolving the problem. This may also include resolving issues related to morale within the team.
Now, morale can be a team problem, or it can be a problem with specific members of the team. I remember a large project I was involved with, critical to the future of our team. Rumors started floating in that the project was being cancelled since the client was dis-satisfied and would drop the project. However, senior management was not conveying any sort of decision and team members were getting very low in morale, with the subconsious feeling about why work so hard for customization for a client where the project would be dropped.
It is in such a situation that the Project Manager and the team leads have to play a critical role. One part is to try to find out from senior management about whether the project is indeed being cancelled, or was there a chance. Once the status is know as well as knowledge about what parts can be shared with the team, it is important to share status with the team on an ongoing basis. Getting information from rumors can be incredibly bad for morale, it is better to discuss within the team, take questions and ensure that people are in a better way, and getting into such a discussion helps (and this is applicable not just in a case where the project may be cancelled, but there may be other issues that could cause morale problems).
More tricky is the case where one or more of the team members are having morale issues, or some other emotional issues. This is tricky to resolve when this kind of problem is causing productivity issues (and in a lot of morale and emotional issues, there will be impacts on productivity). It is the responsibility of the Project Manager and the team leads to identify cases where a team member might be having some kind of morale issues. This kind of becomes critical when there is an associated impact on productivity. Discussion needs to happen with the team member, although the discussion can become very limited if the issue is more of a personal or family nature, something that the manager needs to handle with some delicacy. What cannot be left unsaid, whether delicately or clearly, is that the impact on productivity needs to be set right - the Project Manager would be remiss in his or her duty if this is not handled well. 

Emotional stability - Somebody's got to remain in control during a heated discussion

This was a painful episode when seen in highlight, and something that has stayed with me the rest of my career and even intruded into my personal life. I did not do something outrageous, but the concept of making your way down a path where there is no easy way back has remained with me ever since, and everytime I get into a situation where it could become problematic, I recall the incident to see that I am not boxing myself into a corner.
The exact incident could vary, but the scenario is the same. You are Project Manager / Program Manager of a team with colleagues who have different roles, and their emphasis at different parts of the schedule is different. At a particular point in the schedule, even though both Development, Usability and Testing are supposed to be on the same wavelength, their focus and push could be different, and that is very natural. In this particular case, the situation happened at the time of the schedule when we were supposed to stop all new feature work, from that point on, all the focus would be on resolving defects in the features already implemented.
This is a critical moment for the testing team, since they essentially consider this the time when the entire product comes together, with all features working to some degree or the other (one is really considering a development process that is not ideal scrum). The integration testing happens more critically from this point onwards, and it can take a lot of time from this point in the schedule to thrash through most of the defects and make the product stable (of course, you cannot find all the defects in the product). The testing team is expected to not welcome any addition of new features from this point onwards.
This was a critical time. Some of the members of the development team had come in mid-cycle, so there was already some instability in the team, and it did take them some time to understand the product code and understand the team dynamics and work together as a team. At this time, the Product Management came in with a critical new feature (that had been introduced by the competition) which was expected to take another 2 weeks to develop, with the remaining testing time being around 1.5 months. Now, this was not an easy situation. The testing team was well justified in terms of not agreeing to take this feature, since in the end, it was their responsibility to ensure that the product was stable and had the least number of defects possible. The product manager was quite serious in terms of the need for this feature, and was pushing for it. The development team was ready to implement it.
The first meeting to discuss this was a disaster, with these stated positions being discussed, and getting heated. For me, unfortunately, being the Program Manager, it was my responsibility to ensure that the discussion remained in reasonable limits of discussion, without getting heated, and nobody getting into an inflexible position. However, in this case, at some point, the discussion went into a thread of policy and schedules, and it turned out that I started taking a more inflexible position, whereby such a change would not be possible. The discussion terminated soon after, and it got escalated, and during the midst of a discussion with my manager, I realized my mistake (while I was being chewed out). In every discussion, typically the managers need to ensure that discussions need to remain on a civil level, discussions can get heated, but nobody should reach a point where they get into a position from there was no roll-back, and certainly not the Project Manager / Program Manager. 

Working on items in your status report that are critical and moving them to a green status

For a good Project manager or Program Manager, maintaining the status of the project is one of the most critical items that they need to do. The status of the project is a dashboard that reflects on the status of the various risks and issues that may be faced by the project, and which can cause delay or otherwise imperil the schedule of the project.
For any project, there are a large number of items that can cause problems to the schedule of the project, but not all of them are problematic at the same time. A risk or issue may be small or minimal at some point in the project and be much more significant at another stage of the project, and it is upto the project manager to have the current status of the project in hand at all stages of the project.
So, you have a situation where the project manager already has a listing of all the major items or issues that can cause a risk to the project and is also on the lookout for more such issues that could cause risk, and it is very important that the project manager highlights the risks that are significant at this point of time and brings them up to the attention of the management team of the product.
But it is not just the highlighting of the risks that is a primary job of the project manager. The project manager is not just somebody who reports the issues and risks of the project, but also takes the lead in trying to solve the risks / issues. For this purpose, the project manager needs to have a good understanding of the risks / issues and work with the relevant people for understanding how the risk needs to be mitigated. This needs to be followed by actually working out the mitigation plan (and if these are known risks or issues that were known even before they were actually a risk, then the mitigation plan would already be known) and ensuring that the mitigation plan is as per the actual risk, since even for a known issue, the actual mitigation plan depends on the exact scenario in which the problem occurred.
In some cases, the mitigation plan does not depend on only the team but may need help from outside the team. For example, there may be a situation where the team is behind in the schedule and needs more people helping out the team, and this cannot be solved by the team; the similar is the case when there is a dependency which needs a resolution from outside the team. In such cases, the project manager should bring this plan to the management team of the product where it can even be escalated to outside the team and to senior management if required. It is the responsibility of the project manager to drive this process and reach a point where the plan has helped in reducing the critical status items of the project to less than critical where they can then be managed to become a normal problem.

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.

Program Manager - Ensuring that risks are consolidated and controlled

One of the most critical areas of a software development project is about tracking the status of the project, and ensuring that the various risks of the project are controlled. No matter whether somebody says that their work is important, but these are the most critical items of the project. A definition of risks is difficult, but for our purposes, we would take a risk as something that could cause a problem in the project. What are items that could be risks for the project and would need to be controlled:
- Features taking more time than estimated (either because estimation was not correct or because there were problems during implementation).
- There are problems with the defects cycle in the project. This can be such as more defects being generated, defect ageing being a problem, more defects being rejected after fixed, and other issue in the defect cycle that can cause problems in the project execution.
- The team faces resourcing problems - these could be because of attrition, or the adequate number of people not being there in the project, or tensions between team members or other such reasons related to resourcing.
- Components being used in the software application can cause problems because of delivery or quality issues. So a component that is being used in the project is getting delayed which has a dependency problem in the project schedule or there are quality problems in the component that are unexpected.
- There could be a change in the feature requirement during the cycle. Now, such a change is not expected, but it can happen if a competing product comes out with some features that have been welcomed or some surveys come out with a view that the feature mix is not correct. In such cases, it is not wise business wise to continue with business as-is, and so there would be changes needed which will impact the project.
These are some of the key project risks that you would enumerate at the start of the project and then track through the project. But of course, these are only some of the risks that can come up in the course of a project. The beauty (or the horror of a software project) is that any new risk can come up anytime, and the only thing you can do is to figure out why you had not projected the risk at the start of a project, and how to handle it now.
Take an example of a risk that we had not anticipated during the course of the project. We were working on some new features for our project, and the Program Manager (I don't like to use the first person while speaking about responsibilities) had listed down a set of risks based on his experience (and also after discussion with some other senior members of the team) with the objective of tracking these risks and mitigating or handling them as they emerge. However, suddenly a shocker came.
We got a query from our legal contact about some user data collecting code that we were using in one area of our project. We had a component that we were using for data collection, and so it seemed fine since the component had been verified by the legal team in terms of privacy practices. However, our team had gone a bit ahead and used the component to collect some data which was going beyond the privacy criterion. This has gone by for the past 2 versions without any problems, but in a standard review we were doing for some new work, one of the legal team members had a query about what we had done earlier, and that lead to some serious trouble.
We had to redo the work that we had done 2 cycles back, the developer who had lead that particular project had left for another team, and we were already a bit behind in the schedule. These are the kind of ongoing risks that a Program (or Project) Manager need to consolidate and track, ensuring that the required people are aware of these risks, that mitigation strategies are in place and whatever work is needed to be done by the team or by external folks are all either in progress or are just waiting for the necessary confirmations. Without these, a software project would totally go haywire.

Risk planning - Accounting for when estimates are prepared by one person and task done by another

Let me admit it straight out, this is a pretty difficult topic to write about. In all my years of experience as a manager, trying to have a simple equation or factor for working out what happens when somebody prepares an estimate and somebody else has to do the actual development / coding for that work was not possible. There was no one size fits all for this kind of situation. In the previous post on this topic (Using a confidence level for estimates for later refinement), I put some initial thoughts on this subject. The idea was that estimates are prepared at the beginning of a cycle and can be different from the actual effort put in when the work happens on that features.
It could be argued about why estimates are needed to be prepared at the beginning of the cycle, but there can be many reasons for that. One of the biggest reasons was about wanting to have a good idea about the number of features that would be possible to be done in the given cycle. This is necessary for the team, and this is very important for the stakeholders and sponsors of the team. In a number of cases, the plan for the release will not be approved until there is an assurance that a Minimum Viable Product has not been planned. Given that the release of a product can have profound implications on the financial status of an organization, it can be very important to do planning about the number of features that can be fit into the release.
Doing this estimation also allows the team to do the required resource planning, and even though the number of resources may not change too much between releases, if there is a need to do a big bang release, then the team would want to know the number of extra resources that are required for this release. So, let us work with the assumption that the team needs to do the initial estimation for the features that are planned for the release.
Now, the biggest problem that occurs is that when the work for a release is being estimated, the people doing the estimation are the more senior developers in the team. Typically, the estimation exercise can only last for around 5-10% of the total time of the release, and it is really not possible to do the logical task of breaking down the features into detail deep enough that the estimate would be very accurate. So, a lesser number of people are drafted in to do this kind of work, and an equal assumption is that the estimation is primarily done by the person using their previous experience to determine the scope of work for the details of the feature and using this for the future.
But when it comes to doing the actual development work for the feature, you cannot have these senior people doing all the work. The work is shared among the team members and this is where discrepancies come in. You can have the senior person being very skilled in doing such work, but the person who is actually doing this work is not so skilled and you end up with more effort required for doing this work. So, whenever the work allocation is being done, there is a need to map the estimate with the person who did the estimate, and the person who is actually going to be doing the work. A skilled manager who knows both these people would be able to do this to a large extent and be pretty accurate in this. At the same time, the project manager should continue to track and compare the effort discrepancy mentioned by the engineering manager with the actual effort discrepancy.

Risk planning - Using a confidence level along with estimates so that these are refined later in the schedule

The normal cycle we would follow was for a 6 month period of software development. Every 6 months we would release the next version of our software, and towards that end, we had a list of features ready for the Product Manager to consider for prioritization and decide which features would make it in the next version of the software, and which would be taken up in future versions of the software. Once such a list was prepared, the next step was to get the Product Manager to spend time with the designer and break down the feature set into a slightly more detailed set, something like Use Cases. However, the level of detail that we could do in the time period that we had was of a level higher than Use Cases (the actual Use Cases would be generated only when work on the features was about to start).
Once this level of detail was generated, the next step was to get the senior engineering leads talking to the Product Manager and the designers to get some idea about the feature, look at some workflows and implementation, and then, start looking at how to estimate these. There are many methods of estimation, but in most cases we used the method called heuristics, which is a fancy word that we took to mean that these people knew how to do feature development, they had been doing it for quite some time, and as a result, they would be able to use their experience to determine the typical effort required for doing the feature.
Next, all the effort for the list of features was tabulated, and then assigned to the different members of the team while doing balancing, ensuring that everybody got a mix of interesting and boring work (wherever possible if there was exciting work, since that would help in terms of morale). There was some rationalization of the effort reported to take into account that some of the team members were more capable while others were not so capable. Finally the list of features would be generated to be presented to the stakeholders of the team and the organization.
However, once the team would start actually doing work on these features, then the actual effort would come into play. It was quite possible that the initial effort that was listed was the final effort once the team started implementation, but there was also a high chance that the effort would change once the team actually started implementation. There could be design issues that were not expected before actual implementation started, or there could be other setbacks that happened. It could be that the person doing the estimate had not done a correct estimate and this was clear when the team actually started the estimation.
This has an impact on risk planning. Part of the continuous effort to monitor the risk involved in the project is to determine the actual state of the project and also to determine whether the features that were expected to be done in the initial planning are on schedule or not. However, it should be part of the risk matrix to try and determine the level of inaccuracy present in these estimates (even though it can be pretty difficult) and to estimate the impact this could have on the feature schedule. It is critical that the Project / Program manager has been tracking the estimate accuracy of the features and is not majorly surprised if a feature is running late because of estimation issues.

Concept of Project Scheduling - What is the root cause for late delivery of software?

After all the important elements are defined for a project, it is now time to connect all the elements. It means a network of all engineering tasks is created that will enable you to get the job on time. The responsibility for each task is assigned to make sure that it is done and adapt the network. The software project managers does this at the project level and on an individual level, software engineers themselves.

Project scheduling is important because there are many tasks running in parallel in a complex system and the result of each task performed has a very important effect on the work that is performed by other task. These inter-dependencies are very difficult to understand without project scheduling.

The basic reasons why software is delivered late are:
- Unrealistic deadline by someone outside the software group.
- Changing the requirements of customer and not reflecting them in schedule change.
- Underestimate of amount of effort and number of resources required for the job.
- Non considerable predictable or unpredictable risks.
- Technical difficulties that are left unseen.
- Human difficulties that are left unseen.
- Lack of communication or mis-communication among project staff.
- Project management is not able to judge that project is falling behind schedule.

The estimation and scheduling techniques when implemented under constraint of defined deadline gives the best estimate and if this best estimate indicates that the deadline is unrealistic, the project manager should be careful from undue pressure.

If the management demands that the deadline is unrealistic then following steps should be done:
- A detailed estimate is made and and estimated effort and duration is evaluated.
- Develop a software engineering strategy using incremental process model.
- Explain to the customer the reasons why the deadline is unrealistic.
- An incremental development strategy is explained and offered as an alternative.