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.

---

Tackling Feature Creep: Lessons in Effective Product Management and Project Delivery

When managing software projects, success doesn’t depend solely on having skilled individuals in key roles. It also hinges on how teams navigate scope, requirements, and real-time adjustments. Our experience with one such project showed us just how important structured planning and boundary-setting are—particularly when it comes to managing scope expansion, also known as feature creep.

We had a great Product Manager for one of our flagship software initiatives. She was highly knowledgeable, had strong working relationships with the product support team, and direct lines of communication with several of our enterprise clients. Her ability to gather customer feedback and translate it into actionable requirements made her an invaluable part of the project.

The design team appreciated how she worked with them to evolve high-level ideas into detailed specifications, facilitating the creation of high-level design documents (HLDs) that were both comprehensive and realistic. Moreover, she remained actively involved throughout the design and development phases, consistently available for clarifications, reviews, and feedback. Her dedication earned the trust of everyone on the team.

Yet, despite all these strengths, we continually ran into a frustrating issue: teams consistently found themselves rushing to meet final feature deadlines. On multiple occasions, developers worked weekends and late nights in a last-minute sprint. Remarkably, we never missed our deadlines by more than a day—and we always met the quality benchmarks. But the strain on the team was undeniable.

During project retrospectives, team members flagged this pattern, asking why it kept recurring and why we couldn't better plan for it. They pointed out that while commitment and hard work were admirable, this recurring last-minute push was unsustainable. Something needed to change.

---

Identifying the Root Cause of Project Pressure

To get to the bottom of the issue, we launched a structured investigation. There was always a chance that we had flawed time or effort estimation processes. Alternatively, some feared that certain developers might not have been contributing their fair share.

Two of our most experienced leads were tasked with reviewing the project documentation, HLDs, effort tracking sheets, and defect metrics. Their goal: identify where and why our estimations consistently fell short.

What we found was surprising—but also enlightening. Time spent on core tasks—requirement preparation, coding, testing, and documentation—was generally in line with projections. In a few instances, certain segments had a 20% overrun, but there was no clear pattern linked to specific individuals or phases.

The real issue? Feature creep.

---

Understanding Feature Creep in Project Environments

In project management, feature creep refers to the uncontrolled expansion of product features beyond the original scope. It usually happens incrementally—one small change here, one improvement there—until the cumulative impact becomes significant.

In our case, this occurred subtly. As HLDs were being prepared and development moved forward, suggested enhancements came in—some from the development team itself, and many from the Product Manager. These were almost always well-intentioned. They improved the product, addressed edge cases, or reflected late-stage customer feedback.

Because these changes seemed “minor” and “beneficial,” there was a tendency to implement them without formal impact analysis or schedule adjustment. No one wanted to push back. After all, we were building something better for the customer.

But over time, these small changes added up. They chipped away at buffers, consumed developer focus, and led to crunches near the end of each development cycle.

---

Changing the Process: Structuring Scope Management

Once we identified feature creep as a recurring issue, we knew we had to act. Continually burning out the team wasn’t an option. We needed to instill a discipline around how post-freeze changes were handled.

Our solution was simple but effective: after the design freeze, any new requirement—regardless of size—would be classified as a “feature enhancement.” These enhancements were treated like change requests or defects and entered into a formal review and approval process.

We set up a Feature Enhancement Review Board composed of tech leads, QA, and product representatives. They met weekly to review all proposed enhancements. Only after careful evaluation of the effort, risk, and impact on schedule would a change be approved.

---

Outcomes of the New Approach

This change immediately brought several benefits:

1. Clarity and Visibility: Everyone could now see what was being added post-freeze and why.

2. Better Decision-Making: We were able to weigh the customer benefit of a change against its impact on delivery timelines.

3. Improved Accountability: Product suggestions weren’t automatically implemented; they were scrutinized just like technical defects.

4. Informed Resource Planning: Teams could plan capacity with fewer surprises.

Perhaps most importantly, this new framework ensured that the final sprint before release wasn’t a chaotic, high-stress period. Developers could plan their time more predictably, and team morale improved as they regained a sense of control over their workloads.

---

The Role of the Product Manager: Balancing Value and Discipline

This experience also reshaped how we viewed the role of our Product Manager. Her instincts were always customer-first and value-driven—but even the best intentions can have unintended consequences.

By including her in the Feature Enhancement Review Board, we preserved her vital input while also encouraging a more strategic approach. Instead of recommending enhancements during active development, she began to note them for future releases unless the business case was strong enough to warrant immediate inclusion.

This helped her maintain her customer advocacy while contributing to better team performance and smoother deliveries.

---

Lessons for Project and Product Leaders

Every project faces the temptation to “just add one more thing.” But without guardrails, those additions become silent killers of time, focus, and quality. Our experience taught us:

• Feature creep is often a process problem, not a people problem.

• Good documentation and post-mortems are key to surfacing hidden patterns.

• Formalizing how changes are proposed and reviewed encourages better planning.

• Empowering the product team with structure—not restrictions—leads to stronger results.

Ultimately, the discipline of saying “not now” is just as important as the innovation of saying “what if?”

---

Conclusion: Managing Growth Without Losing Control

Software development is a dynamic process. Customer needs evolve, ideas improve, and developers discover better ways to build. But growth must be managed.

Feature creep may not always be obvious. It can masquerade as helpful suggestions, customer-centric improvements, or low-effort tweaks. But if not managed carefully, it erodes deadlines, impacts quality, and drains team energy.

Through formal tracking, cross-functional review, and a shared understanding of priorities, we transformed a recurring delivery issue into a point of strength. Our teams now deliver with greater confidence, and our products still evolve—with intention, not chaos.

Avoiding Pitfalls in External Partnerships: Lessons in Prototyping and Feasibility

In today’s rapidly evolving technology landscape, partnerships between organizations are not only common but necessary. They help companies expand their capabilities, improve their market presence, and share resources. However, not all collaborations go smoothly. Some run into critical issues that could have been avoided with better planning and foresight. This article recounts one such real-world experience and offers actionable strategies to avoid similar setbacks in the future.

---

The Background: A High-Stakes Deal with Promise

A few years ago, our organization entered into a promising partnership with a larger mobile-based company. The idea was simple and powerful: we would provide a customized version of our software, which would act as a gateway to their platform. The potential of such a collaboration was immense. Not only would this help establish credibility in the market, but it would also provide a platform for future deals and partnerships.

The marketing and sales teams from both sides worked tirelessly to iron out the details. Our technical team contributed as needed, and before long, the agreement was sealed. There were celebrations, back-pats, and high hopes. As with many such collaborations, the schedule was tight—but then again, what enterprise deal isn’t?

---

Early Red Flags: Complex Designs and Resource Constraints

The issues began to surface almost immediately after the initial excitement wore off. As the formal design phase kicked off, we noticed that the design requirements were more complex than initially anticipated. It wasn't just about repackaging our existing solution; the customizations required deep architectural changes.

Compounding the issue was a lack of technical resources. The initial resource commitment, based on the early scope discussions, was grossly inadequate once the actual requirements came to light. Despite increasing the team size, it became evident that we were not going to meet the aggressive timeline.

---

The Critical Decision: Break the Deal or Deliver an Incomplete Product?

A series of urgent meetings followed. Executives, project managers, architects—everyone was pulled in to evaluate options. After weighing the pros and cons, a decision was made: rather than delivering an incomplete and potentially damaging solution, it would be better to step back and break the deal.

It was not an easy decision. There were risks to our reputation and fears about the impact on future collaborations. But ultimately, preserving the long-term relationship and ensuring product integrity took priority.

---

Post-Mortem: Where Did It Go Wrong?

With the dust settled, it became clear that a post-mortem analysis was essential. And the results were illuminating. The most glaring issue? A lack of deep technical engagement before the deal was signed. While our marketing and sales teams did a commendable job sealing the deal, there was limited interaction with the actual product owners and technical leads.

We had entered the agreement without fully understanding the feasibility of the required customizations. The timelines and resource commitments were made based on superficial knowledge of the technical scope.

---

Key Takeaways and Strategic Fixes

1. Mandatory Technical Feasibility Review

Every future collaboration would now require a dedicated phase for technical feasibility. This means having the engineering team review the requirements in detail and provide input on timelines, risks, and resource needs.

2. Build Prototypes for Large Deals

For major contracts, we instituted a policy of building quick prototypes. This not only helps validate technical assumptions but also acts as a proof-of-concept to show the partner what’s possible. A working model beats a thousand PowerPoint slides.

3. Cross-Functional Planning

Deals are no longer closed without joint sessions involving marketing, sales, engineering, and product management. Everyone must sign off before moving forward.

4. Realistic Resource Commitment

No more best-case assumptions. Project plans now factor in possible delays, developer onboarding, testing cycles, and quality assurance.

5. Transparent Partner Communication

We now maintain complete transparency with our partners. If something can’t be done in a specific timeline, we communicate it clearly. Most clients appreciate honesty over surprises.

---

The Bigger Picture: Why Prototyping Matters

In situations, where rapid development and deployment cycles are the norm, prototyping plays a crucial role. It allows teams to:

• Identify integration issues early

• Get real-time feedback from stakeholders

• Validate assumptions and reduce rework

• Improve team alignment

By implementing quick and iterative prototypes, development teams can reduce time-to-market and improve product quality.

---

Conclusion: A Lesson Worth Remembering

While our failed partnership was a difficult experience, it became one of our most valuable lessons. It reshaped how we evaluate deals, plan timelines, and collaborate across teams. Most importantly, it taught us the importance of upfront technical validation and the role of prototyping in making smarter business decisions.

In a world where speed often trumps caution, taking the time to do a proper feasibility check can make all the difference.

---

📘 Recommended Books on Partnerships & Prototyping:

• Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf (Affiliate link - purchase from Amazon)

• The Lean Startup by Eric Ries (Affiliate link - Amazon)

• Prototyping: A Practitioner's Guide by Todd Zaki Warfel (Affiliate link - Amazon)

• Team Geek by Ben Collins-Sussman, Brian Fitzpatrick (Affiliate link - Amazon)

📺 YouTube Resources to Learn More:

Software Development Partner: 10 Considerations Before Hiring

Establishing a Technology Partner Program 

---

Disclaimer: This article is for informational purposes only and reflects a personal experience. Every partnership is unique and should be evaluated based on its specific context.

Ensuring Accuracy in Status Reports: The True Status for Project Success

A status report can be a powerful tool in project management—or it can become just another routine task that gets overlooked. When done right, it provides a clear, honest snapshot of a project’s progress, helping teams and managers make informed decisions. But when it’s inaccurate or overly polished, it can mislead stakeholders and hide critical issues that need attention. In my experience, I’ve seen status reports used in very different ways, each highlighting the importance of accuracy and clarity. In this article, we’ll explore why the true status matters in a status report, how to present it effectively, and the lessons I’ve learned along the way. Whether you’re a new project manager or a seasoned professional, understanding how to craft an accurate status report can make a big difference in your project’s success.

The Role of a Status Report in Project Management

A status report is a document that summarizes a project’s current state, including progress, challenges, and next steps. It’s often shared with team members, management, and stakeholders to keep everyone on the same page. But its importance depends on how it’s used. I’ve seen two very different situations that show this clearly.

In one case, the status report was a key document that many members of management reviewed closely. They often had questions about the details, which reassured us that the report was valued and taken seriously. Knowing that management was paying attention made us double-check the report before sending it out. We wanted to ensure it was accurate—not too optimistic, not too pessimistic, but a true portrayal of the project’s status at that moment. This scrutiny from management motivated us to be thorough and honest, which ultimately helped us address issues early and keep the project on track.

In another organization, status reports were part of a process certification requirement. Every project had to generate different types of status reports, which were sent to a central project management office. The idea was that anyone could access a project’s status report and review its timeline whenever needed. While this sounded good in theory, I noticed a problem after a few weeks: the project manager was overwhelmed by the sheer number of reports they had to produce. It was clear that most management wouldn’t have the time to review more than a couple of these reports in detail. This made the process feel more like a box-ticking exercise than a useful tool, and it highlighted the need to focus on quality over quantity when creating status reports.

The Importance of Accuracy in Status Reports

The main focus of this article is the accuracy of the status report—something I learned the hard way early in my career. When I was a novice project manager with just a few months of experience, I worked with team leads to create status reports. At the time, we lacked the maturity to handle this task effectively. Most people, including myself, saw issues in a status report as a reflection of their own performance. So, our initial reports would mention problems, but we’d add a layer of “sugar-coating” to soften the impact. We’d highlight the issue but quickly follow it with an overly positive explanation of what the team was doing to fix it, hoping to make ourselves look better.

One day, a senior manager called me in for a discussion that changed my perspective. His feedback was clear: a status report is supposed to show issues as they really are, along with what the team can do to address them—not a polished version that hides the truth. He emphasized that issues need to be presented accurately, especially when they could pose serious risks to the project, often marked as “red” items. These red flags might need immediate attention, either from within the team or from external teams we depended on. Hiding or downplaying these risks could delay solutions and put the entire project in jeopardy. This lesson stuck with me: the true status, even if it’s not pretty, is what helps teams and managers make the right decisions.

Challenges of Reporting the True Status

Reporting the true status can be tricky, especially when it involves highlighting serious problems. I remember the first time I included a red item in a status report—I got called into a meeting with the leads of development and testing, along with my boss. They weren’t happy that I had listed an issue as red, signaling a major risk. Their expectation was that any red issue should be resolved quickly so it wouldn’t appear as red in the report. They felt it reflected poorly on the team, and there was pressure to downplay the problem.

I held my ground, explaining that the issue was indeed a significant risk and needed to be addressed, not hidden. After some discussion, we came to an agreement that worked for everyone. Going forward, if I identified a red item, I would communicate it to the team the day before the status report—or sometimes on the same day—so we could discuss it first. This didn’t mean I would remove the red status unless I was convinced it was no longer accurate. If the issue still posed a major risk, it stayed in the report as a red item. This approach allowed for open communication while ensuring the status report remained honest. It worked well for our team and became a standard practice for future reports.

Why Honesty Matters in Status Reports

Being honest in a status report is crucial for several reasons. First, it builds trust with your team and stakeholders. If management or clients sense that you’re sugar-coating issues, they might start questioning the reliability of your reports, which can damage your credibility. An accurate report, even if it highlights problems, shows that you’re transparent and committed to addressing challenges head-on. This transparency can lead to better support from management, as they’ll know exactly what’s needed to keep the project on track.

Second, honesty helps identify risks early, allowing for timely solutions. For example, if your project depends on an external team to deliver a component, and they’re delayed, marking this as a red item in your status report can prompt management to step in and expedite the process. If you downplay the delay, the issue might snowball, causing bigger problems down the line. Accurate reporting ensures that everyone is aware of potential roadblocks and can work together to overcome them.

Finally, an honest status report sets realistic expectations. If you’re overly optimistic, you might promise deadlines or outcomes that aren’t achievable, leading to disappointment later. By presenting the true status, you give stakeholders a clear picture of where the project stands, helping them plan accordingly. This can prevent misunderstandings and keep everyone aligned on the project’s goals.

Tips for Creating Accurate Status Reports

Based on my experiences, here are some practical tips to ensure your status reports reflect the true status of your project:

• Focus on Key Issues: Don’t overwhelm your report with every minor detail. Highlight the most important issues, especially those that could impact the project’s timeline, budget, or quality.
• Use Clear Labels: Mark serious risks as “red” items to draw attention to them, but be prepared to justify why they’re red. Use “yellow” for issues that need monitoring and “green” for areas that are on track.
• Communicate Early: If you spot a major issue, discuss it with your team before including it in the report. This gives everyone a chance to address it and ensures there are no surprises.
• Balance Honesty with Solutions: While it’s important to report issues accurately, also include what the team is doing to resolve them. This shows that you’re proactive, not just pointing out problems.
• Double-Check Your Data: Before sending out the report, verify that all information is correct and up-to-date. An inaccurate report, even if it’s honest, can cause confusion.

The Impact of Accurate Status Reports

Accurate status reports can have a big impact on a project’s success. They help teams stay aligned, ensure stakeholders are informed, and create a culture of transparency. When everyone knows the true status of a project, they can make better decisions, whether it’s allocating more resources, adjusting timelines, or addressing risks. This clarity can prevent small issues from becoming big problems, saving time and stress in the long run.

For project managers, mastering the art of status reporting is also a career booster. Being known for delivering honest, reliable reports can build your reputation as a trustworthy leader, opening doors to more responsibilities and opportunities. It’s a skill that takes practice, but the payoff is worth it—both for your projects and your professional growth.

Applying These Lessons in Your Projects

If you’re new to project management, start by creating simple status reports that focus on the most critical aspects of your project. As you gain experience, you’ll get better at identifying what needs to be highlighted and how to present it. Don’t be afraid to report the true status, even if it means showing problems—it’s better to address issues early than to hide them and face bigger challenges later. Over time, you’ll develop a process that works for your team, ensuring your status reports are both accurate and effective.

For those already familiar with status reporting, take a moment to reflect on your current approach. Are you presenting the true status, or are you tempted to sugar-coat issues? If it’s the latter, consider adopting a more transparent style—it might feel uncomfortable at first, but it will lead to better outcomes for your projects. Open communication, clear reporting, and a focus on accuracy are the keys to making status reports a valuable tool, not just a routine task.

Resources for Learning More

Want to improve your status reporting skills or learn more about project management? Here are some helpful resources to check out.

Amazon Books on Status Reporting and Project Management:

• Project Management for the Unofficial Project Manager by Kory Kogon, Suzette Blakemore, and James Wood (Buy book - Affiliate link) – A beginner-friendly guide that covers status reporting and other key project management skills.
• The Fast Forward MBA in Project Management by Eric Verzuh (Buy book - Affiliate link) – A comprehensive book with practical tips on creating effective status reports and managing projects.
• A Guide to the Project Management Body of Knowledge (PMBOK Guide) by Project Management Institute (Buy book - Affiliate link) – A standard resource for best practices, including how to report project status accurately.

YouTube Videos on Status Reporting and Project Management:

• “What Goes Into a Project Management Status Report” by ProjectManager – A step-by-step video guide on creating clear and accurate status reports.

• Project Management Status Reports [WHAT TO INCLUDE].

• Improve Communication and Transparency by Requiring a Weekly Status Report

A Personal Reflection on Status Reporting

Looking back on my early days as a project manager, I realize how much I’ve grown in my approach to status reporting. That feedback from the senior manager was a turning point—it taught me the value of honesty and accuracy, even when it’s uncomfortable. Now, I make sure my reports reflect the true status of a project, and I’ve seen how much it helps in keeping things on track. I hope these insights inspire you to create status reports that are both truthful and impactful for your projects.

How to cope with team members (or functional teams) who do not easily follow deadlines / schedules ?

Aah, this is one of the most difficult posts to write, since there is no magic bullet answer. Let me take a situation where you have some team members or functional folks who are not really up to working with schedules, or are disciplined about schedules as the development or testing members of the team. What happens typically ? You have a schedule that has been worked out pretty diligently, that takes into account the work of different team members and functional folks, and gets them all integrated with each other to have a schedule that promises, if you follow the schedule, that you will have your software application ready.
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date

Creating mailing list, and place for keeping documents for specific projects

This sounds so simple, but these are measures that can make a lot of difference to the successful execution of a project. You start out with a project which is different from the regular stuff that you are doing, with some people working for this project either on a full time basis, or on a part time basis. For example, while working on your regular project, there is a need for a patch to be released for a previous version of the product which was there in the market, and for which some security issue was found and which needs to be fixed. The teams and organizations that I have worked with typically do not have specialized teams for such tasks, with these instead being done by the core team as well; however, additional resources could be provided as required. In fact, there might be the need for some additional resources for the testing effort, since this would require a high amount of testing in a short period of time.
Finally you are getting the team together which we will be working to execute this project, and the team is brought together for a kick-off meeting where the basic objective of the project, the responsibilities, etc are defined for all the team members and their leads.
But, given the short nature of such projects, there are some specific challenges that come into focus, especially when it comes to items such as communication, and reducing the stress that people come under. For such short projects, there is a high amount of work that is expected to be done within the required timeline, and the team managers need to do all they to ensure that the scope for minimization of activities that could cause stress is there.
The other major problem is communication. Quite often, some communication happens between two or more team members that is important for the project, but there are people who miss this kind of communication. In the normal run of things, people affected will eventually learn about this communication, and things will not go out of control. However, when you consider the short duration of such projects, some communication that gets missed by a couple of team members when it was relevant to them can cause problems in the execution of the project. Setting up project specific emailing lists and encouraging the team members to use such email lists works well in ensuring that everybody gets communication related to the project.
At the same time, there is the need to setup internal sites and document repositories that capture information about the project, including a specific set of requirements and design, as well documents that capture the evolution of these (including comments and queries and answers that came up during the actual discussion to finalize these documents). Having such facilities ensures that people can refer to them easily enough, and new members to the team can pick these up fairly quickly.

Project schedule: A team member departs and a feature is at risk - What do you do ?

This is the kind of situation that no project manager would want to land into. You are into a tight project, and like any other project, there is some amount of tension in the product (it has always been my understanding, and more that of my managers as well that if everything is going fine in a project, there is something wrong with the planning; some amount of tension in the project is necessary for the team to work perfectly and work at full capacity). You have the confidence that with effective project management, which includes some great risk and issue management, you will be able to ensure that incoming issues that could imperil the schedule of the project are handled well, and if there are issues that are beyond your control, you have escalated them to the right set of stakeholders for the next action.
However, there are some set of circumstances that can cause a lot of tension in a project, such as the concept of the team falling behind in the implementation of the initial agreed set of features. At the start of a project, the team and the Product Manager typically agree to a set of features to be implemented during the project schedule. These features also have a minimal set of important features that need to be implemented without fail for the product release to be deemed as worthy of release.
Now, the team is implementing these features and are at the second half of the schedule. Some of the features have been implemented, but there is still critical work remaining to be done. At this stage, one of the team-members working on one of the important feature has to leave - whether this be due to attrition, or the team member having to leave become of some personal emergency. Now you are in a situation where one of the important features deemed necessary for the release of the cycle is at risk, and you need to figure out what you need to do. Here are some possible options, some of which will work while others would not work:
- If the person is leaving because of attrition, then the leaving date discussion can be tweaked to ensure that the person finishes the work and then leaves.
- If the person is leaving because of an emergency, and even in the case of attrition, the transition from the leaving team member to the person who is the replacement needs to happen, and if the amount of work pending to be done is less, this can happen very quickly.
- If the team is a bit ahead of schedule, then it would be possible to still get the important feature done, without stopping any other work. However, if this does not seem possible, then it would be important to ensure that the relevant discussion happens with regard to dropping one of the less important features and getting the more important feature completed.
- If the amount of time left is less, and the completion of the important feature is at risk, then it is important to have a conversation with the stakeholders to ensure that experienced team members are brought in from another team to get the work done.
In all such cases, it is important to ensure that you review the current situation, determine the resource situation and the amount of resources required to complete the important feature, and have a discussion with all the stakeholders. In the extreme situation, if there is a need to ensure that the feature needs to be done and the schedule is at risk, then the schedule may need to be extended to ensure that it is done.

Sending a weekly list of tasks for the team at the beginning of the week

As a part of project management, it is very important to ensure that the team has adequate knowledge of the tasks that are coming up in the near future. If you maintain an updated task schedule, then the task schedule will have an updated list of the tasks for each team member, and this should be easily accessible to the team members. It is important that the team members be given access to the schedule and task tracking tool with the required level of access rights. Them not having access to the tool would put a lot of pressure on the project manager to control the tool, and also be accessible whenever a team member needs access to the tool, either for viewing a certain detail, or for modifying a certain detail.
However, it is also a reality that in many cases, especially when you have a team that is not so mature, there is a resistance to accessing the tool (and this may be justified to some degree; I have seen many tools that combine a high amount of functionality into the UI of the tool with the assumption that it will be primarily accessed by the project manager and can be fairly cumbersome for a developer or tester to update). As a result, you end up with a situation where the team members has not really accessed the details of the upcoming tasks and there are delays (and this can be almost comical if it was not serious to the schedule - once when I asked a couple of team members about why they did not check the details of the schedule in the tool to review their upcoming tasks; they put the blame on me about having a horrible tool and why I did not inform them about the tasks in their name).
Based on all this information and after discussion with the team managers, there was felt the need to actually send out a communication of the tasks that are doing to coming to team members in the upcoming week. So, we worked on setting up a report (or rather, 2 reports) which tried to provide the following details:
- A large list of the upcoming tasks for the week across all the team members. This would list the tasks per day as well as the team member and the estimated days. This list was also printed and up on a large board next to the team's physical location where they could see the list at all times. We also encouraged the team members to actually run a line through a task that was completed, which was a good way of letting the team see that there were tasks that were getting done.
- In addition to this, the other report went at individual level. This report listed out the ongoing tasks for the person, the upcoming tasks for the week and the tasks that were also expected to be completed in the upcoming week. This report was more detailed, and there were enabled links in the report that would take them the team members (via the login process) to the section of the tool where they could update their tasks. This particular report was however tweaked to ensure that team members could log into the report site and do customization - one team member had typically broken up his task into 2 day chunks and he had set the report to come to him once in 2 days, ensuring that the report was very useful for him.

Impact of any change in the final schedule date

A product development cycle can be fairly chaotic. When you hold a finished product in your hands or have it installed in your machine, the product would look great and you would not even think about the intense passion and drama that is part of the process involved in bringing out such a release. Most teams start out with a concept that this cycle of the product release will be simple, and have a lower amount of tension in the ongoing release. However, it has been my experience that a large number of such releases can be incredibly full of tension; you enjoy bringing out a product that is liked and purchased by a large number of users all over the world, but the times when you are working on the product cycle can be enjoying and frustrating at times.
One of the most tension filled times is the last week and last days of the schedule; you are this close to making the release date, you wonder whether there is anything that was forgotten; you pray to whoever you hold dear and holy that there are no major defects that come up in the last few days of the release cycle that can have an impact on the quality or the schedule of the release. In most cases, changing the release date of the product is next to impossible given the number of items that get shaken up. What happens when you have to change the release date:
- All media communication is screwed and it can end up as a PR disaster worrying people about the quality of the product
- There is a huge impact of the confidence of the senior management in the team management especially when this schedule release impact comes up suddenly
- There is a revenue impact, since as part of finance sheets, there would already have been a calculation of the revenue that will come; any change in this date will cause some shortage in the revenue sheet. If this is a major product, it could actually spiral all the way to change in earnings of the organization.
- There are many processes that are already set in motion such as DVD production, retail channels, and delivery to other partners, and all of these are impacted. For example, if your product is planned to be loaded as part of the installed software on OEM's such as the desktop or laptops of HP, Sony, Dell, etc, there will be hell to pay. These partners have finely tuned schedules and it will take some major negotiation for these schedules to be reset.
- The team would already be high-strung because it is near the end of the cycle. They are expecting a period of down and low tension for some time after the release, and if the release is delayed, this can cause morale issues within the team and continued tension.
- If you are using partners and vendors along with the core team, any delay of the schedule will also need more time for these teams. For example, vendors who provide language translation and review services can be pretty expensive, and any schedule delays will need to factor these in.

As a result of these reasons, and more like them, the team always needs to be on the ball. It would be real bad management and estimation if something happens in the last few weeks to cause the schedule to be changed. There can always be legitimate reasons for a schedule to get changed, but these should be known well in advance so that preparations for all the reasons listed out above can take place.

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.

Dealing with dependencies that can impact your project schedule ..

Dependencies are the bane of a project schedule, or as one of the developers in a team told me, dependencies and other risks are the reason that a team needs a Project or a Program Manager. I have had informal discussions with some of the senior members of the team, as well as the members of the management team, and there is a lot of discomfort in handling the various dependencies that bedevil a project; as well as doing all the negotiations that are required to mitigate the risk of a dependency, or when the dependency causes a problem to the project.
What am I talking about ? Well, consider the fact that in today's world, most projects have a lot of dependency on items outside the control of the core team. You may be getting some work done from outside the core team by an external team, you may be picking up a component that has been created by an external team (which can be somebody who you pay for delivering the component, or you may be picking up a component that is being done by a open source type of team which produces a component and you pick up the component as and when it is prepared).
However, anytime you are using an external component, you are exposing yourself to a dependency and to a high amount of risk (actually the risks depends to the extent on which the dependency can screw your project). Let me list down a few examples:
- You use a component that is fairly stable (say, being done from another team in your organization). The component is fairly stable, and even though new versions of the component are released from time to time, there is no major necessity of picking up a new version of the component. The dependency is there, but the risk is low and so the mitigation required is also low. Even if there is a problem with the latest version of the component, you can stay with the version that you already have.
- You use a component where there is a bug fix that is needed for solving a problem in your application. In such a case, the risk to your product or project schedule depends on the critical nature of the defect in your application. If the defect is critical to your application, then you have a high amount of dependency and need some mitigation plans. If the component has some problem, then you have to consider the impact on your project and have mitigation plans accordingly. If you are able to survive with the defect in your software, then you would not imperil your schedule if there is any problem in the delivery or the quality of the component.
- Now consider the case of a component that is critical to your product, or delivers a functionality that is critical to your component. For example, when you consider the Adobe Camera Raw and the products that incorporate it, one of the critical advantages that a new version of the Camera Raw provides is support for new Digital SLR's that have been released. So if you were releasing a new version of Photoshop or a new version of Lightroom, it is important for them to integrate the latest version of Adobe Camera Raw because of this support for new cameras. In such cases, if a component is delayed, it causes significant problems for the product schedule and needs a high degree of mitigation. In this case, the mitigation that is done by these products is by enabling this component to be updated later. However, the mitigation strategy for every such component or dependency may not be so easily solved, and the team needs to ensure that there is a lot of thought to how to mitigate these problems.

Ensuring that you have knowledge of changes in components that you integrate ..

Most modern day software applications use a number of components within them. The advantage of using components is that these components can get a lot of specialized functionality implemented through them, which would otherwise be difficult and hard to implement if the application development team wanted to write all this functionality. And even if the team was able to do all this, just maintaining all these specialized features can be a big problem. Consider the case of a software which needs to create a video that needs to be burnt onto media such as CD/DVD/Blu-Ray. Now, all of these are specialized features that are done pretty well by many components, both open source and commercial. However, if the product team wanted to write all this functionality as a part of their product, they would need to also make sure that they are maintaining all this code. Even for this specialized job, there are a lot of maintenance that needs to be done. The code for this area needs to be work on any new optical media that is introduced, such as when Blu-Ray's were introduced, and when new versions of Operating Systems for both Windows and Mac emerge, the features should work as well. For all this, it is a better strategy to ensure that components are used for specialized functionality.
However, there are some risks that come out when using components, and these risks can exist whether the component is from another group within the organization or from an external organization. One of the biggest risks is when the component is being used by multiple software applications, and your application does not have dedicated use of the component. In such cases, there is a need to be somewhat more informed about what the changes are that are happening in the component. Even if consider the above case about a component that allows writing to a DVD, another product that may be using the component may request for a change in the component for some need of theirs. And the component makers may decide that such a need is genuine and put in the required feature.
There is an even chance that the new feature that has been put in may not impact your application, but there is still a chance that it may have an impact on your feature workflow. For example, you may be using the component in a silent mode, whereby no dialog from the component may show up, but another organization requests a dialog to show up for a need of theirs. In such a case, you would need to ensure that you know about this, and the discussions with the component makers would need to ensure that there would be a way of ensuring that such a new dialog does not pop up in your workflow, such as a parameter that could be passed from your application code to the component which ensures that the new dialog does not pop up.
In all such cases, even though it is the duty of the component maker to have a list of changes in the component from the previous version, it is also your duty to check that none of the changes impact your application. And if you are integrating an open source component, you may not have the ability to get the external team to make any changes to their application, so you need to very carefully check their changelist and see the impact this has made on your application. Only if there is no impact should you incorporate a new version of the component in your application.
This is one of the risks of your project planning and depending on the number of components you use and the profile of those components, can be a high level of risk that needs to be checked at a regular interval.

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.

Open up the feature planning and tracking to the team for improvements ..

In the previous post on this topic (Risk planning by looking at confidence level of estimates), I talked about the difficulties posed due to discrepancies between the original estimates done at the time of planning, vs. the actual efforts spent on the work when the features are in development. Tracking these discrepancies and working out some kind of logic about these discrepancies is very important for the project manager. Typically, the estimation is done by the senior folks on the team while the person who works on a specific feature can be anyone on the team (if the work is specialized, then it would be allocated to somebody who has more experience in that area, but that person could still be different from the person who did the actual estimation).
So what do you do ? Well, you would typically track the estimation against the effort, and try to figure out whether there is some kind of logic. Sometimes, there is a possibility of generating some logic to figure this out. We had a case whereby the person who preparing the estimates had a person situation during the time that he was working on the estimations which was very distracting (but not enough that the Project Manager could figure out that here was a problem). So, soon after the actual work started, some data analysis about the discrepancies resulted in figuring out that the actual effort was about 25% more than the estimates where this particular person was involved, and this helped us in re-estimating the remaining features and also making a decision that a particular feature needed to be stripped down, the scope of the feature reduced for getting everything in the time frame.
However, what was interesting was that this logic was actually seen by a member of the team who pointed this out, and though it seemed a bit strange at first, more analysis helped. Some speaking to the people who had already worked on the features that this person estimated tended to confirm that they believed that the features were under-estimated. What this incident showed was that this provided us (the leads and the project manager) that we should get the team more involved with the risk planning and analysis that we do, such that sometimes it would be possible for them to identify a pattern that we might miss. There were other smaller cases that we could see.
One problem that was told to us before we started was that it was supposed that this would distract the team members from their regular work, and, many of them might not be interested in being involved in such kind of analysis. We did find people who were not interested, but we did start out with the entire team, making them involved with the process we did for identification of risk factors, gathering the data and then doing the analysis. About the time it took to do this, we figured that overall this would take an hour per week, but getting team members involved with stuff such as this would help give them a better perspective on some important processes that team leaders go through and when they could see the problem, they had a closer perspective on some of these risks and could figure out solutions for a percentage of these cases faster than we could. This helped save time overall, and after a couple of rounds, the people who elected to remain involved were appreciative of the learning they got from such exercises.

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.

Trying to determine a risk index based on heuristics - would be a good start

Risk planning is a critical part of any project / program manager's job. Anytime during the course of a development cycle, the project may be exposed to a number of risks. If the team has not done as well a job of risk planning as it should have, they can land in a very unpleasant condition; and even if they do got help, the first question that anybody would fire at the manager would be about not properly anticipating these kind of problems and being ready for such problems as they occur.
So what can you do in terms of risk planning even before a project has started, and then continue doing through the course of a project ? There will be always be new risks or problems that will arise during the course of a project that have not happened previously or did not have the same gravity earlier, but there will always be risks that could have been anticipated in advance. And this is where a good project / program manager can excel, in terms of doing a good job at risk planning.
So what does this mean ? Well, the simplest case is if you are working on a new version of a product where there have been earlier versions. In such cases, if you have been around for previous versions, you typically have a good idea of what the risks are like and also know some ways of handling such risks. For example, you know the time period in which defects tend to peak, you know the time periods in which resourcing can become an issue, you know about components that you integrate which can cause the maximum damage to your schedule because they are either late or of bad quality. With all these, you can start to prepare such a list of problem areas.
Typically, risk planning is not something that comes of age in one version. What is required is to ensure that all problems and issues that you face in the previous version of the product have been recorded in some way, along with a note about the critical nature of the issue and the time period in which such an issue came out. With these as an input, an experience project / program manager can figure out which of these issues can become risks in the current versions of the product, and plan accordingly. If issues are not recorded, then you lose out some part of doing an effective risk planning for future versions of the product or project.
It is also necessary to find out more areas of risks that you would not know. There are risks that come to other people in the team, typically to the development or quality teams, which are known by their managers. For example, once we ran into a huge problem due to a different version of Visual Studio that we needed to upgrade to, and one of our components had a consistency problem with that version. This was something that our development managers knew would happen every other version, but we did not know from the project/program management side. It turned out to be a huge risk for the project, with the potential to need cutting out an important feature or add some more weeks to the schedule, and that did cause problems since it was not there in the list of risks, and yet was an old risk.

Differentiate between Capability Maturity Model (CMM) and Scrum?

In the year of 2002, when both the CMM (capability maturity model) and agile software development models were on the list of the highest demanded software development methodologies, the CMM model and agile processes were considered to be to pretty much same.

But, later in the same year two of the software engineers Jain and Turner argued that these two software development models or processes have much difference between them if investigated in detail.

This article discusses about the differences between the cmm model and agile methods. There is no fixed or appropriate way to develop a software system or application but at different stages a different methodology is to be adopted. 

Coming to the scrum, it is a pre defined development life cycle based entirely up on the agile principles. The CMM on the other hand comprises of many practices that can be adopted by a team so as to improve its overall performance. The CMM model pays more attention to the areas that require change and project management. 

Another aspect of the CMM is focussed up on the following three aspects:

1.      Engineering skills

2.      Organizational learning

3.      Advanced project management

Differences between Capability Maturity Model and Scrum

Difference #1:

- In CMM, it is required that an understanding is developed with the requirement

providers  based upon the definition of the requirements.

- In Scrum, there are reviews of the requirements listed in the product back log with

development team and product owner.

Difference #2:

- In CMM, commitment to the requirements is demanded from all those involved in    

the project. 

- In Scrum practice, the commitment is needed in the sprint planning and release 

planning.

Difference #3:

- In CMM, practice any changes to be made are directly carried out on the

requirements.

- In Scrum practice, the changes are recorded in the product back log and are worked 

up on in the later sprints.

Difference #4:

- In CMM, it involves the identification of the inconsistencies among the work 

products and the requirements.

- In Scrum practice, the inconsistencies are identified during the sprint planning and

release planning sessions.

Difference #5:

- CMM develops a top level work breakdown structure for the proper estimation of the  

project scope. 

- In scrum, the standard tasks combined with the specific project tasks define the 

scope of the project.

Difference #6:

- In CMM, the attributes of the work products and tasks are maintained kept for the 

maintenance of the estimates.

- In scrum, this task is done with the help of story points.

Difference #7:

- In CMM, the whole project budget and schedule is prepared in CMM.

- In scrum, a project is broken down in to several sprints and for every sprint there is a 

separate schedule and back log.

Difference #8:

- The main estimates that are carried out in CMM are of the resources required to 

perform the development tasks. 

- On the other side, the scrum maintains the estimates of the sprint back log, release 

plan and assignments.

Difference #9:

- In CMM a plan of involvement is prepared for all the stakeholders separately during 

the planning process.

- In Scrum, there are predefined core and ancillary roles that saves a lot of time.

Difference #10:

- In CMM, at the end of the day the project plan is re-conciliated to check out the 

available resources.

- In scrum, there is sprint planning meetings and daily scrum meetings to do this task.

Difference #11:

- The project development in CMM is tracked by monitoring the actual values of the 

project parameters against the already prepared project plan. 

- On the other hand the scrum is aided by the sprint burn down charts for the same 

purpose.