Tag: Facilitation

Realizing Value:The Latest Trend or Here to Stay – Part 2

Written by Elizabeth Larson on March 7, 2016. Posted in Articles. 7 Comments on Realizing Value:The Latest Trend or Here to Stay – Part 2

In January we published our annual article about the seven trends in business analysis and project management. In Part 1 of this article we discussed the relationship of value to all of the trends. We also defined that very ambiguous term.

We showed how innovation for the sake of being innovative and Agile for the sake of being Agile was meaningless as ends in themselves. Finally, we looked at the first two trends through the prism of adding value to the organization. In Part 2 we will discuss value in relation to the other 5 trends.

Trend #3 Moving beyond our traditional PM and BA roles

We predicted that traditional BA and PM responsibilities would be augmented by involvement in strategic activities. This strategic focus is needed to ensure that our initiatives bring value to the enterprise as a whole, not just segmented interest groups. We said that project managers would be increasingly focused on delivering the benefits and value outlined in the business case and charter and that business analysts who can question the strategic implications of projects and facilitate understanding the real business need behind stated needs will provide increased value to the organization and its customers. In other words, both project managers and business analysts will be expected to add value by ensuring that they deliver it.

Trend #4 Lightweight practices are not just for Scrum anymore

We emphasized that project managers and others are finally making peace with the idea that delivering value is what matters, not whether or not they’re Agile or how Agile are they. As we said, the angst increasingly is no longer about whether organizations or teams can call themselves Agile; but rather whether what they’re doing benefits the organization. We are happy to see that the industry conversation has already begun to shift from being Agile to providing value “agile-y.”

Trend #5 Certifications – and the winners are. . . .

Certifications and professional designations are almost always obtained to provide value. Sometimes the value is to the organization. For example, hiring certified PMs, BAs, or scrum masters means that the hiring organization can rely on a level of knowledge and consistency, thus avoiding training and onboarding costs. Sometimes the perceived value is to the individual who feels that the designation will increase their value to a hiring organization. We do not know which certifications will be perceived as providing the most value to individuals or organizations or, for that matter, how much value they provide. However, we do know that the number of PMPs, CBAPs, PMI-PBAs, CSMs, and CPOs continues to increase and will for the foreseeable future.

Trend #6 Designs during analysis bring business value quicker

{module ad 300×100 Large mobile}

To understand how this trend focuses on value, it is helpful to understand the distinction between requirements (descriptions of the business need) and designs (descriptions of the functionality needed to build the solution). Requirements help us understand what problem needs to be solved and/or what opportunity is out there for the organization to take advantage of. Designs are not technical specifications. They are features of the solution which will address the business need. Remember that requirements and designs are not separate phases of the project lifecycle. They are both part of business analysis. So how do designs add value? By developing designs in conjunction with requirements rather than waiting for the requirements to be fleshed out, we enable each feature to be developed and delivered sooner, thereby creating value sooner.

Trend #7 Workforce trends are impacting project work and organizations

There are a number of trends related to getting work done and the need for value.

Communication is increasingly becoming less formal and more frequent. Therefore, the cost of meetings, formerly associated with formal, scripted, inflexible agendas is decreasing. That is not to say that we will return to the chaos of disorganized, unproductive meetings. It means that the facilitator as dictator and gatekeeper of a formal agenda is a thing of the past. As part of this trend, we are starting to reclaim some of the connectedness we recently lost working virtually. People now realize that face-to-face meetings are generally more effective and can be shorter than virtual meetings, despite the improved online tools. This translates to lower costs and increased value.

This means that meetings will need to be valuable to the participants. Having short, informal, face-to-face meetings that can quickly get to the desired meeting outcome enables participants to spend more of their time working towards their operational business objectives. It follows that the better they can meet their goals and objectives, the more value they bring to their organizations. Meetings that are “fantastic wastes of time” and which do not add value will no longer be accepted.

Similarly, to address the preferences of many younger workers, learning events are becoming shorter and more personalized. Increasingly they need to be seen as highly valuable. Social media will help ensure that large numbers of people become aware of low-value learning events, which will ultimately lead to low attendance and eventually its demise.
Organizations are beginning to adjust to the fact that they need to add value to employees if they have any hope of retaining them. Both younger workers with new ideas and older workers with knowledge and experience will present a challenge to organizations who have to continually find ways to provide value to these workers and motivate them to stay.

In summary, the seven trends that we discussed in January are not separate trends. Each contributes to the overall value that PMs and BAs provide to organizations. And, they are definitely here to stay.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

The 95% Rule for Agile Leaders

Written by Robert Galen on February 1, 2016. Posted in Articles. 3 Comments on The 953 Rule for Agile Leaders

Now that I think about it, a “rule” sounds a whole lot more formal than I intend it. Perhaps I should call it a guideline or a heuristic or a thinking tool?

Ah, I don’t know. Let’s get into it and make that determination afterwards.

http://www.3playmedia.com/customers/case-studies/mit-opencourseware/

The Rule

It’s simple really. It revolves around telling your teams what to do. That is providing your directives, strong opinions, and guidance when you’re interacting with your fledgling Agile teams.

The premise is that for every 100 opportunities that you are confronted with in your organization to provide prescriptive advice to your teams, you get no more than 5 times actually to tell your teams what to do.

You have to keep the tally in your head.

You have to be honest about it.

You shouldn’t tell anyone else you’re doing it. It’s just for you.

What does the rule do?

As leaders, it helps us by:

• Preventing us from micromanaging or being overly prescriptive.

Forcing us to carefully consider our engagement points with the team.
Hopefully, it encourages us to keep a few opportunities in reserve, in case there is an emergency intervention needed
In general, it causes us to pause and think before we go mucking around our teams – telling them what to do.

But it does give us the opportunity to, dare I say it, LEAD because it also encourages us to engage when it matters the most.

Circumventing the Rule?

I hate to say it, but you can circumvent the rule. How, might you ask?

{module ad 300×100 Large mobile}

You can circumvent it by asking, carefully crafted, open-ended questions of your team. Not trick questions or leading questions, but true curiosity questions or important questions that your teams may be missing.

These questions are intended to get your teams thinking about things from a different perspective. And they are fair game, in that they don’t count against your 5 allowed prescriptive comments.

Wrapping up

I told you it was simple.

And I know what you’re thinking. Is this something I made up OR do I actually use the rule myself?

I actually use it. And I’ve found it helps me to achieve the balance I need to be an effective Agile leader. My hope is you find the same with it.

Oh and, let’s leave it as a RULE for now. I think you’ve got to practice and earn the right to loosen it up a bit.

Stay agile my friends,

Bob.

Eliminate Unhealthy Tension to Achieve Agile Success!

Written by David Shaffer on January 26, 2016. Posted in Articles. 4 Comments on Eliminate Unhealthy Tension to Achieve Agile Success!

The success of implementing an Agile methodology within a software development group is dependent on establishing trust amongst the various roles of the product development team.

A typical team consists of a Business Analyst, a Product Manager, Project Manager, Developer(s), Tester(s) and possibly a validation representative. Establishing trust among each role is dependent on the establishment and communication of clearly defined responsibilities and areas of authority within each role. If these responsibilities and authority levels are not defined and understood by each role, then it is guaranteed that team members will stray into areas of authority they do not have causing conflict and friction within the team. All too often the time is not taken to clearly define roles and responsibilities before converting to an Agile methodology which results in the following negative effects:

Finger pointing and blame between roles
Low morale and disillusionment with the Agile methodology
Potential turnover and loss of key contributors
Disappointment with the actual benefits gained by implementing Agile

So the obvious question is “How should a product development group be organized with clearly established roles and authority levels to improve the probability of Agile success?” Before I answer this question, in the spirit of full disclosure I would like to acknowledge that the framework I am about to explain was originally taught to me by a VP of Software Development whom I greatly respect and admire. I have simply added information concerning the symptoms of healthy and unhealthy tensions between groups. Understanding unhealthy tension is useful to identify when your group is suffering from a misalignment of responsibilities. This framework is based on dividing a product development group into specific Functional Areas, or Levers, which Executive Management can apply pressure to as needed to correct issues as they arise. Interactions between each Functional Area can be monitored for specific symptoms which indicate whether the team is experiencing healthy or unhealthy tensions.

Like death and taxes, it is impossible to avoid tension on a software development project. Tension is naturally created by the need to satisfy specific business needs and meet commitments related to the success criteria of a project. It is imperative that a BA or PM is able to determine whether the project is experiencing healthy tension or unhealthy tension. Healthy tension naturally occurs as a result of a collaborative team all striving to achieve the same goals. When each Functional Area is operating within their realm of responsibility and authority an environment of trust and respect develops amongst team members. This healthy environment results in a highly functioning collaborative team willing to go the extra mile for each other to solve problems and deliver high-value solutions to the business. Unhealthy tension is the direct result of Functional Areas straying outside their realm of responsibility and authority. When this occurs the team which has their area of authority breached will react negatively and the seeds of team discontent will be sown. By now you are probably wondering what these Functional Areas are and how their responsibilities and authority levels are defined.

Our department has had success implementing an Agile methodology by organizing the development group into the following four distinct Functional Areas or Levers.

Product Management & Business Analysis (Product Managers & Business Analysts)
Technical Delivery (Developers and Testers)
Risk Management (Project Management/PMO/Scrum Masters)
Process Governance (QA/Validation)

The Product Management & Business Analysis group is responsible for working directly with our customers to understand their unmet business needs. Product Managers work to understand the marketplace and industry in which your company’s solutions compete to derive a product development roadmap. The roadmap is prioritized and optimized for maximum revenue and market share gains. The Business Analysts work closely with the Product Managers to interpret these unmet business needs into clearly defined requirements. Product Managers prioritize the requirements for development and ultimately are responsible for approving the final product for release after they are satisfied the solution meets the business needs. The Product Management & Business Analysis group has full Authority over the selection of business analysis tools, the organization and writing of requirements, product level decisions related to solution functionality and the ultimate approval of each software release. Symptoms of healthy tension within this group are characterized by the Technical Delivery team questioning requirements and their associated business needs as well as helping Product Management ensure the correct business needs are being solved. Symptoms of unhealthy tension in this group are BA’s taking orders and writing them down or writing requirements according to how the technical team or project management team prefers them to be written. Once other teams start dictating the structure and organization of the requirements, you will see significant unhealthy tension between the groups.

The Technical Delivery team consists of the Architects, Technical Managers, Developers and Software Testers responsible for developing and testing the solution. This team is fully responsible for selecting the software development and testing tools, designing the system architecture, writing code, testing the application, developing the test strategy and providing timelines for completion of the work. They have full Authority over the architecture choices and decisions, the technical implementation of solutions, and the overall test strategy and testing toolset. You may be a bit surprised that the Technical Delivery team has authority over timelines in this structure. During our implementation of Agile, this was an enormous source of contention and strife. The Project Management group and Executive Management struggled with giving up their command and control practices of dictating deadlines they felt were realistic or necessary. The reason for providing the Technical Delivery team with the authority over timelines is to place the responsibility for estimating the effort and duration of the work directly with the people doing the work. Dictating deadlines to technical teams typically results in unhealthy tension. This is especially true when an unrealistic deadline dictated by management results in the team working nights and weekends to finish the work! This is a common example of functional areas straying outside their realm of authority. Unfortunately, our Technical Delivery team suffered through much unhealthy tension over this misalignment throughout a two-year development project. The best defense against this occurring on your teams is to ensure the consistent delivery of commitments made during the sprint. Once management experiences consistent delivery of sprint commitments they will be less likely to dictate irrational deadlines.

The Risk Management group is comprised of the Project Managers and is typically referred to as the Project Management Office or PMO. The PMO is responsible for monitoring project risks and reporting on those risks, reporting overall project status, removing roadblocks and facilitating team collaboration. They have complete authority over the metrics used to report risks to the project and project status. Symptoms of healthy tension within this group are characterized by the PMO collaborating effectively with Product Management, Business Analysis, and Technical delivery to identify and understand risks to the project and identify roadblocks they can assist with. For example, other teams may be struggling with obtaining external resources to answer questions or having hardware infrastructure acquired and setup. The PMO can effectively work to remove these types of roadblocks to facilitate project completion. Signs of unhealthy tension within this group consist of differences of opinion on project scope leading to arguments about scope creep, the PMO dictating excessive process details such as the time/frequency of Agile meetings, and the PM’s dictating how requirements are written and organized. During our implementation of Agile, we suffered through each of these symptoms. The PMO had a difficult time releasing their command and control mentality and trusting the teams to make correct choices on the use of Agile tools and completing their work. When the Agile process is supposed to deliver great efficiency benefits, it is easy to place far too much emphasis on the process. At one point, we even heard from the PMO that if people didn’t follow the process they would get people who could! Obviously this caused a serious amount of unhealthy tension amongst the groups. As time went on and the delivery teams were consistently delivering high-quality software, it became easier to convince the PMO to release control and empower the teams to choose how they should work within the process.

The Process Governance group consists of the Quality Assurance team. They are responsible for ensuring adherence to departmental process, documenting validation processes and training the department on those processes. Their authority consists of defining the minimum requirements needed to adhere to the external regulations our products are required to meet. Healthy tension in this group is identified by QA understanding the complete SDLC and collaborating with the other Functional Areas to implement the most efficient processes to satisfy regulations. Unhealthy tension can be identified by repeat process noncompliance. This can indicate a passive-aggressive approach against a process that is considered to be inefficient or unnecessary. Occasionally the QA group strays outside their authority and recommends certain changes to how requirements are organized. Our team experienced this when QA requested that all completed requirements affected by Change Requests have their iteration path updated to reflect the path in which the CR was completed. This request was based entirely on how their validation reports worked and would have caused a tremendous amount of busy work for little value. Fortunately, the teams collaborated and chose an agreeable solution which allowed QA to get the information they required via a simple query from our requirements tool.

While I have spent considerable effort outlining an effective organization structure to implement Agile, I must also explain the responsibilities and authorities which are common to the entire development team. The entire team is responsible for ensuring that solutions are developed to satisfy well-defined business needs. This is the entire team’s responsibility. The team is also collectively responsible for ensuring all regulatory requirements are met and processes are followed. Successful Agile implementations will provide the entire team with the authority to choose the Agile tools necessary for their particular team based on the team’s experience. This is absolutely critical and can only be accomplished by management and the PMO releasing some of their command and control tendencies. As our teams matured throughout the course of a two-year project, it became apparent that daily standups and retrospectives every two weeks were becoming ineffective. Providing the team with the empowerment to decide when to change the Agile tools and the frequency of their use ensures healthy tension is maintained. When the team is self-directing and self-correcting issues as they arise without management interference, you know you have a healthy team. Symptoms of unhealthy tension within a team can typically be spotted pretty easily. Finger pointing and blame between functional areas, the team working excessive hours to achieve objectives, low morale, turnover, and requiring management intervention to solve team disagreements are all very common symptoms of unhealthy tension. If you are experiencing any of these symptoms, it is likely that functional areas are beginning to stray outside of their realm of authority. If management keeps their hands on the four levers I have outlined it is easy for management to make a correction.

From the Sponsor’s Desk: Nine Criteria for Project Prioritization

Written by Drew Davison on January 25, 2016. Posted in Articles. 11 Comments on From the Sponsor’s Desk: Nine Criteria for Project Prioritization

In most organizations, the demand for project work far exceeds the funding and resources available. Approaches to resolving this challenge vary from pitched power struggles, rigorous portfolio management practices and demand management arrangements to siloing strategies and executive dictates.

In this post, we’ll look at a company that came to grips with the excess demand challenge using a simple, nine point ranking process. Project proponents used the tool to quantify the potential enterprise value of each proposal. All submissions were then ranked to select the top value proposals. The cut-off was established based on the estimated level of affordability for the upcoming year, nicely matching demand with capacity. Simple, consistent, fast and good for the organization.

Thanks to I.B. for his contributions in this case.

The Situation

This manufacturing organization faced an ongoing challenge to balance demand for project resources with organizational value, affordability and the profit expectations of its shareowners. Past attempts to deal with the issue had resulted in the use of a number of new practices: in-depth business cases, funding allocations by division based on a high-level assessment of divisional contribution to strategic objectives, quarterly funding allocations, and a formal gating process.

The CFO was still not satisfied with the prioritization and funding approaches. He believed that many short and long-term profit opportunities were being left on the table. He discussed his reservations with his CEO and other senior executives but found support to address the issue lukewarm at best. So he set out to see what other organizations were doing to address the challenge as a prelude to revising their own internal practices. He assigned one of his Finance managers to take on the challenge.

The Goal

To investigate best practices being used by market leaders in their industry and in other industries, assess how those practices were contributing to organizational success, and make recommendations to improve their own internal operations. The assigned manager was challenged to have a formal, justified proposal in place within six months to coincide with the start of the corporate budgeting cycle. Any funding required would come from the manager’s operating budget with assistance from the CFO’s budget as needed.

The Project

The Finance Manager enlisted a couple of his senior staff and started a literature search for project prioritization and funding practices to get the ball rolling. He also engaged with the Systems Development Manager about key project success factors and project management best practices. The four of them were soon overwhelmed with information. They decided to constrain the scope of the undertaking by developing an assessment matrix that addressed four components:

No more than ten selection criteria
A rating scale for each criteria that would produce a confirmable and quantitative result
Weighting for each criteria that could be adjusted to reflect current corporate priorities
A total score that could be used to rank projects

The Finance Manager also suggested that they stage their efforts to test concepts rapidly, garner feedback and iterate until they had a solid proposal and test the models on their current project inventory and backlog. His teammates agreed. The CFO agreed.

The team of four developed three iterations over fourteen weeks. Each iteration was tested on the current project inventory and the results reviewed with the CFO. Based on qualitative and quantitative assessments, the model was revised, and a new iteration was processed for subsequent review. In three months, the Finance Manager and CFO were ready to present their findings and recommendations to the company’s executives for approval.

The Results

After some stubborn resistance and localized grumbling, the proposed project prioritization and ranking process was approved unanimously by the company’s executives for use in the upcoming budget cycle. The prioritization mechanism included the following components: a stakeholder model, prioritization matrix and a process guide.

Stakeholder Model

Four roles were defined in the Stakeholder Model:

Process Owner – the CFO was identified as the owner of the process and the final arbiter on any issues related to the operation of the prioritization and ranking practice.
Reviewing Partners – the members of the Executive Committee were identified as Reviewing Partners, responsible for vetting every submission to ensure completeness and consistency across the portfolio
Submission Owners – the Sponsors of the submitted proposals were designated as the Submission Owners. They were responsible for the accuracy and integrity of the submissions. They were also responsible for socializing the proposal and ensuring all stakeholders were on side.
Collaborators – the change Targets were identified as Collaborators. They were responsible for signing off on the accuracy and integrity of the submissions before they were presented for consideration

Prioritization Matrix

Nine assessment criteria were selected as the primary indicators of worth and risk with an assessment scale for each. As well, they defined the Value and Weight ratings for the criteria. The team saw the Value rating as an important indicator of project success that would stay constant from year to year. The Weight rating, on the other hand, could be varied year by year to reflect the needs of the corporation, from shorter term, lower risk projects to high strategic alignment.

The assessment criteria included:

1. Sponsors – Sponsorship was seen as a key success factor. However, the more sponsors there were on a project, the greater the risk. The scale was Number of Sponsors, the Value was set at 20%, the Weight at 20% and the total calculated as Value/# Sponsors*Weight.

2. Targets – Targets are the managers/decision makers of organizations affected by a planned change. As with Sponsors, the more Targets involved, the greater the risk. The scale was Number of Targets, the Value was set at 20%, the Weight at 10% and the total calculated as Value/# Targets*Weight.

3. Associated Projects – Associated Projects was included to identify inter-dependencies that needed to be considered during project selection. Of course, the more Associated Projects, the greater the risk. The scale was Number of Associated Projects, the Value was set at 10%, the Weight at 10% and the total calculated as Value/# Projects*Weight.

4. Supported Strategies – Supported Strategies was included to reflect strategic alignment. As well, it allowed for an analysis of potential inter-dependencies and identification of gaps in strategic support. The scale was Number of Supported Strategies, the Value was set at 15%, the Weight at 10% and the total calculated as Value*# Strategies*Weight

5. Strategic Fit – Strategic Fit focused on the significance of a project’s support for stated corporate and line of business strategic goals.

The scale was defined as:

Critical to the success of the line of business and corporate goals	5
Necessary to deliver the line of business and corporate goals	4
Supports the line of business and corporate goals	3
Tactical with strategic component	2
Tactical solutions only	1
Has no direct or indirect relationship to corporate vision	0

The Value was set at 10%, the Weight at 10% and the total calculated as Value*Strategic Fit*Weight.

6. Economic Impact – Economic Impact considered the value expected to be delivered to the organization in terms of annual benefit and payback. The scale was defined as:

under 1 year	5
1-2 years	4
2-3 years	3
3-4 years	2
4-5 years	1
5+ years	0

The Value was set at 10%, the Weight at 15% and the total calculated as Value*Economic Impact*Weight.

7. Competitive Advantage – Competitive Advantage focused on the value derived from implementation of a project supporting a new business strategy, product or service. The scale was defined as:

Substantially improves competitive position (12 month window)	3
Moderately improves the competitive position (6 month window)	1
Brings the level of service/products in line with competition	0

The Value was set at 5%, the Weight at 10% and the total calculated as Value* Competitive Advantage *Weight.

8. Competitive Risk – Competitive Risk assessed the degree to which failure to do the project will cause competitive damage. The scale was defined as:

Postponement will result in irrevocable damage	5
Postponement will result in further competitive disadvantage	4
Postponement may result in further competitive disadvantage	3
Can be postponed for up to 12 months without affecting competitive position	1
Can be postponed indefinitely without affecting competitive position	0

The Value was set at 5%, the Weight at 10% and the total calculated as Value* Competitive Risk *Weight.

9. Project Risk – Project Risk focused on the degree to which the organization is capable of carrying out the changes required by the project. This is a negative factor. Higher measurements represent greater risk. The scale was defined as:

Magnitude of change

Major change for targets	5
Moderate change for targets	3
Minor change for targets	1

Primary target of change

Customer	10
Field or remote locations	5
Internal	1

Management commitment

No active sponsorship	10
Actively managed at mid-management levels	3
Actively sponsored at highest level	1

Project management/skill sets

Inexperienced	10
Somewhat experienced	3
Experienced and capable	1

Cross-organizational implications

Affects all services or lines of business	10
Affects multiple services or lines of business	3
Confined to limited services or lines of business	1

Magnitude of business & technology changes

Major change to existing environment	5
Completely new business or technology	3
Minor changes to existing environment	1

Clarity of business need

Ill-defined	10
Generally understood	3
Clearly defined	1

Knowledge of target solution

Brand new product or service	5
Somewhat new/limited applications	3
Very well-known/industry wide	1

Total

For total scores of 8-26, the risk rating is Low
For total scores of 27-46, the risk rating is Medium
For total scores of 47-65, the risk rating is High

The Value was set at 5%, the Weight at 5% and the total calculated as -Value* Project Risk *Weight, a negative number that reduced the overall project rating. The higher the risk rating, the larger the reduction.

In addition, two additional pieces of information were required: Annual Benefit and Payback Period. At this early stage, it didn’t make much sense to try and develop cost estimates. Instead, the submission proponents were asked to calculate a projected annual benefit and the payback period required based on the nature of the change. For example, operational changes would be expected to provide a quick return (usually less than a year). Tactical initiatives should have a payback within one to three years, and strategic undertakings could have a payback period of three years or greater. That information was used to arrive at target investment amount (annual benefit x payback period). The target investment was used as a proxy for estimated cost on the proviso that the solution would be managed within that number.

The Prioritization Matrix was presented in a worksheet form that submitters were required to complete, socialize, present and defend in seeking funding for their initiative.

Completing the worksheet was an informative process for the participants. They were often forced to go back and reconsider aspects of their proposal to increase the value and reduce the risk in an effort to improve the total score. Often, what started out as a multiple sponsor initiative ended up with one, more committed sponsor. Proposals that had a significant risk were often reconfigured to reduce the risk and increase the chance of funding. On occasion, proposals were dropped from consideration when the sponsor and collaborators realized what looked like a great idea didn’t pan out with further due diligence.

Process Guide

The Process Guide was developed to provide a roadmap for those involved in the project prioritization exercise.

The Process Guide included eight steps, from conceptualization to the final decision regarding the projects to be funded. The sponsoring executive was required to ensure proposed projects were socialized with managers affected by the change and that affected decision makers were in agreement.

Each initiative was presented by the sponsoring executive in an executive scrum. The presenting executive was challenged by his or her peers to justify each position, especially the specific strategies supported and the ratings for strategic fit, economic impact, competitive advantage, competitive risk, project risk, forecast annual benefit and the target payback period.

There were heated debates about most of the submissions and the values assigned. In many cases, the debate was taken offline where further discussions and investigations resulted in modified and resubmitted proposals. The process had two significant benefits: the proposals, when finally approved for funding, where solid, well research, fully supported ventures and, all senior executives were fully informed about the initiatives going forward. The CFO, in his role as process owner, was responsible for making a final call on a proposal if an agreement couldn’t be achieved in the scrum sessions.

The CFO’s staff accumulated a list of approved proposals in a ranking table and ordered it by the prioritization total, below.

Individual project proposal totals and rankings could be tweaked by the CFO’s staff to reflect project inter-dependencies, mandatory initiatives like government legislation, critical operational fixes, and other planning opportunities. Finally, the CFO’s staff would determine the appropriate level of funding to commit for the upcoming period and draw a line across the ranking chart. Projects lying above that total would get funded. Projects below the line would not.

After the first use of the prioritization practice and completion of the budget cycle, the CFO’s staff surveyed those involved to see how the practice met its goals. The almost unanimous feedback: simple, consistent, fast and great for the organization.

How Great Leaders Delivered

From the millions of hits returned on an internet search for “project prioritization”, this is obviously a challenge for many organizations. There are also undoubtedly a plethora of solutions. The CFO and his Finance Manager and team did a number of things right to solve the prioritization challenge for the organization and deliver a solution that was right for them.

Collaborate – The CFO sounded out his colleagues at the outset and received a lukewarm reception. But through that initial contact, the other executives knew something was probably afoot so they weren’t surprised when the proposal was presented to them. Also, collaboration was at the core of the prioritization practice and contributed significantly to its success.
Reuse – The Finance Manager and his teammates started with a broad search for applicable practices. They certainly weren’t disappointed. Reusing what others had developed and discovered before, they were able to develop a practical, powerful solution quickly and cost-effectively.
Test – The team’s decision to iterate, review and test the output on their existing project inventory allowed for a rapid discovery cycle while minimizing the investment of time and accumulation of vested interests. Was their solution perfect? Certainly not. What they did get though was good enough to meet the challenge.
KISS – Keep It Simple Silly. They did keep it simple. Nine factors. A simple scale for each. A Value rating. A Weight rating. An annual benefit. A target payback period. Add them all up to get a total. Review with others. Decide. Oh, and they used Excel.
Measure – The CFO’s team worked with the sponsors and collaborators to complete the worksheets and go through the review and decision processes. They adjusted the materials based on the feedback received. They communicated widely, about usage, number of proposals under development, received, reviewed and approved. They interviewed the executives midway through the budgeting process and made appropriate revisions. They surveyed the users after the budget cycle and communicated the results. They knew how the process was performing throughout the budgeting cycle.

In my mind, this is a great example of a solution fitting the need. It wasn’t the perfect solution. But it was more than good enough. So, if you find yourself in a similar situation, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors. Finally, thanks to everyone who has willingly shared your experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Agile’s Principle Matters

Written by Sandy Rheeder on January 12, 2016. Posted in Articles. 4 Comments on Agile’s Principle Matters

Over the past few years, the adoption of Agile methodologies in larger South African corporates has not been an easy journey. As a consultant in the IT space, I have come across quite aggressive resistance to this approach that puts reality and flow efficiency at its centre and challenges the notion that “more planning next time” is the way to go. Why such a guttural reaction? Where does this come from?

The recent Agile Africa conference, held in Johannesburg, highlighted a root cause I have often seen evidenced – this thing “Agile” is not in fact “a thing”, it’s an adverb, not a noun or verb. It’s not a set of steps you can learn and follow like a recipe. It’s not driven by a tool. To receive the benefits of agility in software delivery, it’s the principles that matter. As a community, I think we have not adequately covered this why element when introducing agile concepts to new ears. Too few “agile practitioners” really understand the principle they are trying to achieve when, for example, they ask teams to stand at a board for 15 minutes every day.

Given this, it was refreshing to be part of a conference where the principles were top of mind. In track 3 at Agile Africa, a space where delegates could come and discuss issues without a fixed agenda, conversations covered things like why business analysts stick to their translation role so much when translation can be null and void in an effective cross-functional team. Interestingly, effective analysis as a foundation for success was discussed as a principle mindset issue on the track 2 agenda. Delegates grappled with the lack of skilled resources in South Africa and came to the conclusion that if we give people an opportunity to fail fast and cheap, we can nurture the talent we have. Especially if we count that process as successful, regardless of the small delivery batch that didn’t work so well. This again highlights the principle of effective feedback on the smallest possible batch, to produce a better result the next time.

What has really stuck with me two months after the conference was the talk on flow mindset, an insight into the way people think when they fully understand the agility principles, and they allow those principles to drive their speech and actions. I say this because changing minds is no easy thing and nothing reflects a person’s mindset better than the words they use. I believe this is why the Agile community has fallen into the trap of teaching practice above all else – following a defined set of guidelines to the letter forms habitual behaviour, which is what we are looking for in the end. But addressing this level alone does not give us the real value that Agile development has promised. Aligned values engage our hearts and our will, and fully understood principles give our minds the critical why that drive us to change our behaviours. When the going gets tough, old habits and the words that go with them will kick in, unless we honestly believe they are not constructive, and we consciously force ourselves to follow a new path. To quote a conference phrase, “Agile without values is without value”.

Perhaps that’s why I am sometimes met with such aggression when I talk about this concept we call “Agile”. Some clients have dabbled in practices under this banner but have not been through an effective change journey at all. When the going got tough, they reverted to doing things the way they’d always been done, yet expectations of faster value had already been raised, so everyone was worse off.

I am empathetic. The principle matter for me over the next 6 months is to try to avoid this trap and elevate the principles and the values to the level they deserve.