The Role of Agile Advocates
Categories:
Agile
Categories: Agile
| This is a continuation of the post Creating Trust in Agile. Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful. Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective? Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed. AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective. The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management. Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology. I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ... Over to you for comment! |
Creating Trust in Agile
Categories:
Agile
Categories: Agile
| Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate. The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership. Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time. The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt. An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end." With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches: We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value. We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way. In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline. To be continued ... |
Working With Risk
Categories:
Risk Management
Categories: Risk Management
| Risk exists at all times. The less planning we do for it, the higher the chance of failure or uncertainty of results. I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology. Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture. Response to risks comes in the form of: - Acceptance - Rejection - Mitigation Organizations must ensure they: - Identify key risk-management processes to map them out to the organization's processes for project delivery - Identify risk factors (i.e., elements that cause probability of risk occurrence to increase) - Standardize risk identification, assessment and quantification, and documentation across the organization Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks. If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk. And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing. How do you work with risk? |
Easy EAC Calculation
| Experts on the assassination of U.S. President John F. Kennedy have come to a couple of conclusions: 1) the Warren Commission got it right and 2) many people have a hard time accepting that such a monumental, history-changing act wasn't the result of a massive, expensive, difficult-to-execute conspiracy. So, when I started writing about how earned value management systems (EVMS) can accurately predict the future with some simple calculations, I received some responses that expressed varying levels of incredulity. It simply goes against intuition that an information element as important as at-completion project costs could quickly and easily fall out of an EVMS. But since I've already firmly ensconced myself at the end of this limb, let me take it a step further: The estimate at completion (EAC)--the brass ring of management information systems--can be calculated without a baseline, a work breakdown structure or a formal change-control process--none of what we've been told are essential parts of an acceptable EVMS. None. Nada. Zilch. Now, I'm well-aware that the previous sentence is the metaphorical equivalent of pulling the pin on a grenade and rolling onto the floor of a conference room full of EVMS experts, but I can explain. The traditional formula for calculating an EAC (EAC = BAC/CPI) can be algebraically reduced to dividing cumulative actual costs by cumulative percent complete. That's right, we're talking two date elements, easily collected. And the resulting information is far, far more accurate than anything that the general ledger can produce. It's also much more accurate (and faster and easier) than re-estimating the remaining work and adding that to cumulative actual costs. In fact, it's so much more accurate, faster and easier than any competing information stream, that I'm frankly flummoxed that the calculated EAC isn't the centerpiece of EVMS use everywhere. I can't wait to see the responses to this one. |
Are You Really Ready for a PMO?
Categories:
PMO
Categories: PMO
| Organizations that have a project management office (PMO) show they are moving toward a centralized management of project resources and strategic alignment to business goals. But I find a certain level of readiness has to exist in an organization for it to create the platform for a worthwhile and cost-effective PMO--the type of PMO that contributes to the business not by simply being an extension that offers extra resources, but that works and evolves with the business. There are key issues in organizations that usually hinder this: • Senior teams do not understand the PMO or its purpose • Senior management teams do not understand what project management is all about and how it can help them lower the costs of implementing projects • The PMO is viewed as something you install without careful and business-aligned planning In my mind, PMO implementation must be viewed and managed as a project. A company should know why it's seeking to implement a PMO in their organization, what business issues it's trying to fix and what inefficiencies it's trying to improve. A company has to consider: 1. Organizational Readiness Organizational processes will require changes to ensure the process flows into and out of the PMO are integrated into the organization. 2. Cultural Readiness The organization has to assess its readiness based on current resource pools, whether the resources can be migrated to PMO teams, and how other members of community will be able to align with PMO requirements based on their knowledge, experience, skills and mindset. 3. Strategic Alignment The goal is not just to have another department, but to have a team of people agile enough to act quickly and in a focused manner. And planning of the PMO has to include reasons that align with direct impacts on strategic goals of the organization. |
