Program Management


Deconstructing Value Is Just Like Demolition!

Deconstructing Value Is Just Like Demolition!

Conceptually, value is fairly simple. Value is a measure of importance or worth. This is where simplicity ends and complexity begins. To determine worth and importance we have to understand the difference between the perceived cost and the perceived benefits. Here is the value equation:

Value = (Benefit + Perception) – (Cost + Perception)

Cost, benefits and perceptions are like a suitcase; they are containers with many different things inside. Let’s unpack those suitcases just a bit.

Thinking like a cost accountant is useful when considering the cost component of the equation. The typical costs that are accounted for when costing an IT project include labor, materials, hardware and overhead. Each of these categories could easily be broken down even further. For example, labor can include internal labor (cost of employees) and the cost of contract or outsourced labor. The cost of all labor needs to be considered. I once ran into an organization that only considered external labor when deciding which piece of work should be done. This caused the firm to make economically unbalanced decisions that reduced the value that they delivered to their clients. Far less typical, but no less relevant, costs that need to be assessed when determining value include opportunity costs, business costs and legal and risk mitigation costs. Opportunity costs represent the benefit that would be gained from the work that is foregone to another piece of work. All work has an opportunity cost. Ranking portfolios of possible work by importance is a way of incorporating perceived costs into real costs.

Interestingly, benefits are often far less tangible than costs. Benefits are always predictions of the future, and therefore are more apt to be impacted by perceptions and cognitive biases. Depending on the type of effort, typical benefits often include improvements in market share, cost savings and revenue enhancements. The forecast of benefits is the result of some form of transformational magic that leverages the predicted impact of a change (what will happening if a piece of software is used) and the probability of use (will it be used and how fast will the uptake be). The transformational magic can be incredibly formal based on market research and statistical interpretation or a reflection of gut feel.

The third component of both benefits and cost is perception. Perception means how we regard, interpret or understand a cost or a benefit. Perceptions is the bucket of factors that reflect all of the biases or gut feels with either the cost or benefits. For example, a financial projection might indicate that a feature will deliver $1,000 of value however the might temper that projection based on his or her feeling about the direction of the market. Techniques such as template driven cost/benefit analyses, parametric estimation, planning poker and Delphi estimation try to ameliorate the impacts of some types of less rational perceptions. Overly optimistic estimation of costs and benefits are types of less rational perceptions (read Optimism: The Good and The Bad).

Value is a shorthand mechanism to reflect the difference between benefits and cost based filtered through the perceptions of those collecting and analyzing the numbers. Value is important to concepts ranging from qualifying which feature to work on (part of #NoProjects), selecting user stories for the next sprint (sprint planning) or as prize for getting code into production as fast as possible (#NotImplementedNoValue). These represent only the tip of the iceberg for how value is used in Agile. Without a firm grounding what the word value means it is difficult to ask a product owner what the value of a particular feature is and then help evaluate the answer.

Hot air balloons and helium balloons

They are all balloons! Using the right word is important for understanding!

The idea that a flow of value to users is at the heart of concepts such as #NotImplementedNoValue and #NoProjects. At the heart of the flow of value is a conundrum. That conundrum is entwined in three terms; price, cost and value.  These three terms are often conflated, despite representing very different ideas. When project teams or product owners use price, cost and value interchangeability they can easily make the wrong choices as they they lead value through the development or maintenance process.

Price is often equated to value. We have all heard “you get what you pay for.” As anyone that has had to bid for a project will tell you, price is a significantly more nuanced than a straight translation of value. Price is defined as the amount of money given in payment for something. Price can also refer to an unwelcome experience or condition required to achieve an end. The act of pricing is dance between what can be charged and the strategy of the seller (think Game Theory). I have heard sales people suggest that they price the first deal to get in the door in order to prove the value of their product or service; therefore the price of any individual transaction might not be directly related to value. All software transactions must be viewed across the life of the software and the life of the relationship with the provider.  Bottom line: Price of any individual transaction is only loosely related to value.

Cost is a “simple” concept. The use of the term simple is very tongue and cheek, as costs often include labor, materials, office charges, hardware, business changes and opportunity costs. In a commercial product, cost and price are connected by the margin. The discipline of having to maintain a positive margin over the long term mean you need to understand the relationship of cost to price and later value. Most internal IT organizations do not face the long-term discipline of the market, and often only have to manage labor costs, which can lead to poor behaviors. One example of poor practice is substituting labor for automation because automation has a higher upfront cost (resisting test automation software for example).

Value is defined on Dictionary.com as ”relative worth, merit, or importance.” Value measures range from profit and revenue, to a relative measure based on the perception of what an individual or group will get from a service or product. To make matters more complicated, the perception of value changes based on context, which can affect what can be charged. For example, water has significantly more value to someone dying of thirst than a person sitting in their kitchen drinking a glass of water. Value can be seen as the interaction between factors that include global or organizational impact, individual benefit and the probability of use. Many people use cost and price as tools to help determine value.

Price, cost and value are related. Cost plus margin will always equal price for a specific transaction. Over the long run, pricing any specific transaction below the typical margin or at a loss may make strategic sense. Examples might include capturing market share or getting in the door. But in the long run, pricing too many transactions below cost is catastrophic. The link between cost and price is more tenuous, because even if measured using hard currency the amount of value is affected by perception. In order to pursue concepts like #NoProject or #NotImplemnetedNoValue you need to have a handle the nuances of price, cost and value so that you can understand and talk clearly about the value derived from each story, feature or epic. Falling prey to conflating price, cost and value will yield a conundrum that will impact the decisions we make about what to deliver and when.

Programming Note: We will dive into value in more detail on Thursday.

How many people is too many?

How many people is too many?

When determining how large an Agile program can be, one of the oft quoted “facts” is that the number of people involved in an Agile program is governed by Dunbar’s number. Dunbar’s number is the limit of the number of people in a group that can maintain stable social relationships. The term, social relationship is a reflection of regular interactions, the ability to recognize another member as part of the group or are committed to a common goal. These attributes are important to any project and are perhaps more important in Agile projects because they rely on team cohesion to minimize bureaucracy and control mechanisms.

The concept of Dunbar’s number is based on research originally performed through the observations of primates and then extended to humans in the early 1990’s. In June of 1992, Robin Dunbar  published “Neocortex size as a constraint on group size in primates” in the Journal of Human Evolution (Volume 22, Issue 6, June 1992, Pages 469–493). In the paper Dunbar noted a correlation between the size of a primate brain and the average social group size. From the abstract, Dunbar wrote:

Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism’s information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group’s size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time.

While group size of 150 is often quoted as Dunbar’s number, 150 is an approximation. As noted in the “Limits of Friendship” by Maria Konnikova (October 7, 2014) Dunbar’s number can range from 100 – 200 (ish) people based on factors such a social gregariousness. Other limits of group size have also been published for example Drs. Peter Killworth and Russell Bernard have published numbers in excess of 200 people.

Based on Dunbar’s number, the Scaled Agile Framework Enterprise (SAFe) suggests that the largest Agile release train (ART) should include approximately 150 people. The ART is supported by a framework (SAFe), hierarchy (release train engineer and Scrum masters) and bureaucracy (product management and product owners). Agile being practiced by a single team of 5 – 9 people would not require this degree of overhead to ensure coordination.

Scaling agile is a balancing act between the efficiency of team-level Agile techniques and the concessions made to control when Agile is scaled up to deal with larger efforts. Historically, very large projects tend to be less efficient. Capers Jones in Applied Software Measurement, Third Edition[1] (p295) indicates that productivity falls for all types of projects as they exceed 1,000 function point points. Function points are an ISO standard method of measuring software size based on a standard set of rules. Simply put the larger a project is in function points the larger the team (or team of teams) needed to deliver the project which yields the need for more control processes all other things being equal. He further makes the point (p 307) that as project size increases, so does the probability of cancellation.

Scaling Agile leverages many of the techniques used by team-level Agile, such as small team size, small batch sizes and Scrum. These techniques are are very lean but are perceived limit the amount of value that can be delivered within a specific period of time. As Agile projects grow in size additional techniques are needed to maintain control. Dunbar’s number (or similar ideas) provides a limit to try to avoid letting a piece of work become too large to manage. The number act as limit to the number of people involved in a piece of work. Applying additional constraints, such as releases or SAFe’s program increment, add a dimension of time as constraint. The combination of constraints on the number of people and the how long those people will be working provide an explicit constraint on how much work can be delivered.

1 Applied Software Measurement, Third Edition, T. Capers Jones, McGraw Hill, 2008

Can you see the man in the moon?

Without a roadmap and a value focus it is easier to perceive that the current “project” might the last one in a while, therefore you need to ask for the moon.

It is often more difficult to take a product focus for applications that will be used internally than for an application that will be used by or sold to an external customer. Part of the issue seems to the distance an application from the ultimate end of the value chain and therefore revenue. The further away from revenue, the harder it is to view the user of the software as a customer. Therefore providing support for tools that enable or support non-customer facing work is often viewed as less critical than customer facing applications or tools. The difficulty in considering internal software as a product is less an artifact of any real difference between internal and external facing applications than perspective. Differences in perspective are typically built on minor differences in organization and market attributes. These differences include:

Ability to switch – Internal “customers” often are hostages to the services provided by internal IT organizations, at least in the short run. While that sounds strong, internal customers often do not have the option to shift providers if they don’t like the service or quality they receive. In the long run, switching can and often does occur either through outsourcing, formation of shadow IT groups in the business or changes in IT leadership. Less flexibility in the short run can often lead to a lack of discipline when it comes to defining product roadmaps or defining the true value any specific feature or function might deliver. Without a roadmap, a form of fatalism can set in, in which users always ask for more than they need at the moment but usually accept what they are offered (after a lot of noisy conversation).

Internal politics – The value of work that is sold or used by external customers is usually easier to measure. Functionality either solves a need and generates revenue or increases customer satisfaction. Developing a value for work to be consumed internally is rarely that cut and dry. Priorities are often defined by considerations that don’t reflect the true quantitative value of the work. Priorities often reflect the requestor’s (or requestor’s group) positional power. In my first job, the head of accounting requests always floated to the top of the list even though we were a garment manufacturer with a sales focus. Prioritization by factors that don’t relate to value makes it difficult to develop roadmaps or plan release for applications that don’t have the same level of political clout. Remember when you hear the saying, “the squeaky wheel gets the grease,” it often means that the organization has a project rather than a product focus.

Talking with Customers –  Another of the differences between internal applications and external products that impacts whether an application is viewed as a product is who needs to have input into direction. Products require discussion not only with internal stakeholders, but also with external customers. Internal applications supported by individual projects only require discussion with internal stakeholders. The lack of a perceived impact outside of the company’s boundaries makes it difficult to generate the motivation to get involvement across the IT/business boundary. For example, it is often harder to identify and get product owner involvement to support planning and work to be used internally. Agile techniques are often a tool to remove the barriers between IT and internal business groups. However it is easier to generate the involvement needed facilitate developing plans, road maps and communication when revenue is involved, which tends to yield a project perspective (short term) rather than a product perspective.

Perceived differences between work done for internal and external use tend to drive internal customers into a more transactional mode. Without a roadmap and a value focus it is easier to perceive that the current “project” might the last one in a while, therefore you need to ask for the moon.

You need both the big and the small picture to deliver value.

You need both the big and the small picture to deliver value.

The concepts of project and product provide two alternatives that might lead readers to believe that one perspective is more important than another. You need both sets of behaviors generated by the project and product perspective. How these behaviors are incorporated into roles on teams is not as straightforward as designating a role representing project concerns and a role representing product concerns and never the twain shall meet. Both roles do not have to be separate people. Agile spreads the project-centric behaviors across the entire team. Even the product owner typically absorbs some of the project-centric activities. However, other than at a philosophical level, the team is not typically charged with performing the product-centric activities. Agile techniques spread project behaviors across the team while product driven behaviours are more concentrated.

Project-centric behaviors are focused on the delivery of the tactical plan, while the product owner has more of a focus on the vision of the long-term future, i.e. the product roadmap. Even though the product owner has a distinct interest in the tactical (what is to be accomplished in a sprint or release), the team has a more focused interest in day-to-day activities. The team must plan, monitor and adjust the day-to-day activities needed to meet their commitments during the sprint (commitments in Agile are by definition tactical). The product owner can contribute, however they typically do not have the technical acumen to deliver functional software. However, without a product view, the day-to-day project considerations will typically trump long-term considerations. In a mature Agile environment, the product view interacts with the project view to generate an equilibrium between long- and short-term perspectives.

Project and product focuses require a different measurement. The project focus on delivery/short-term goals generates a need to understand, pursue and measure delivery efficiency. Efficiency is a measure of transformation; how much of a set of raw materials is needed to create an output. Efficiently producing any output is only valuable, IF what is being produced is what is needed and can be actually delivered. Interestingly most software is a step toward a different product that is bought or used. Because the software being developed or enhanced is a step along a path, the value assigned often does not represent the ultimate impact to the organization (See our Re-Read Saturday series on The Goal for more on this topic). The product owner, as the steward of the product perspective, owns the definition and measurement of value. He or she needs to take the big picture view of what the market needs AND what the market will pay for. What the market will pay for is just as important for an internal product as an external. In order to understand the value a product delivers, the product owner must ask whether the result of a sprint or release positively impacts ROI, profit and cash follow. Efficiency is a mechanism to determine whether a team is making the most out of their “raw material,” but it does not provide feedback on whether what is being produced is the right thing, or whether the functionality delivered yields value to the organization.

In general the product owner will be the champion for the product perspective, however every team member needs to have an understanding of the how the future should unfold and the value they are being asked to deliver. The team will need to temper the product vision based on the constraints that the day-to-day environment provides. Both the project and product perspectives are needed to maximize value. Putting either perspective ahead of the other for any length of time will create an imbalance that will reduce team effectiveness.

Listen to the Software Process and Measurement Cast 292. SPaMCAST 292 features our interview with Dr. Ginger Levin. Dr. Levin and I discussed her book, Implementing Program Management: Templates and Forms. Dr Levin and her co-author Allen Green wrote their go-to reference for program practitioners, colleges, universities, and those sitting for the PgMP. Ginger provides great advice for program managers who are interested in consistently delivering value to their clients.
Note the audio is not perfect this week however the content is great. I hope you can stay with the interview!
Dr. Ginger Levin is a Senior Consultant and Educator in project management with over 45 years of experience. Her specialty areas are portfolio management, program management, the PMO, metrics, and maturity assessments. She is a PMP, PgMP (second in the world), and an OPM3 Certified Professional. She presents regularly at PMI Conferences and conducts numerous seminars on various topics. She is the editor, author or co-author of 20 books focusing on program management, portfolio management, the PMO, virtual teams, and interpersonal skills and is a book series editor for CRC Press. She has managed programs and projects of various sizes and complexity for public and private sector organizations. She is an Adjunct Professor at SKEMA University in Lille, France, in its doctoral program in project management and also for the University of Wisconsin-Platteville in its masters program in project management. Dr. Levin received her doctorate in Information Systems Technology and Public Administration from The George Washington University and the Outstanding Dissertation Award for her research on large organizations. Please see: linkedin.com/in/gingerlevin

Buy your copy of Implementing Program Management: Templates and Forms NOW!

Thanks for the feedback on shortening the introduction of the cast this week. Please keep your feedback coming.  Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us onFacebook while you’re at it.

Upcoming Events

ITMPI Webinar!
On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects. Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

Upcoming DCG Webinars:
June 19 11:30 EDT – How To Split User Stories
July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I look forward to seeing or hearing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.
As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.
Available in English and Chinese.

Listen to the Software Process and Measurement Cast 280. SPaMCAST 280 features our interview with Mark C. Bojeun, author of Program Management Leadership: Creating Successful Team Dynamics (Kindle version). Mark makes a very strong case that project and program managers can impact team culture and dynamics. The team’s culture is directly linked to productivity, quality and morale.

Mark’s Bio

Dr. Bojeun has more than 20 years experience in providing strategic management and leadership through portfolio, project and program management. His experience includes developing and managing multi-million dollar portfolios, programs and projects, facilitating the achievement of strategic objectives, and creating best practice processes for program and project management efforts. Dr. Bojeun has designed and implemented multiple Enterprise Program Management Offices (EPMOs) for domestic and multinational firms and has extensive experience in organizational change management through transformational leadership, strategic support and staff empowerment to management professionals in the development and implementation of organizational vision, mission, objectives, and goals.

Dr. Bojeun holds a Program Management Professional (PgMP), Project Management Professional (PMP) and Risk Management (PMI-RMP) certification from the Project Management Institute (PMI), is a Microsoft Certified Solution Developer (MCSD), and has a Bachelor’s degree in Business Administration, an MBA from George Mason University and a PhD in Organizational Leadership.

Dr. Bojeun’s new book, Program Management Leadership: Creating Successful Team Dynamics as part of CRC Publishing’s Best Practices and Advances in Program Management Series addresses the need for effective leadership styles in managing programs and projects achieving high performing teams that consistently exceed expectations.

Over the last ten years, Dr. Bojeun has provided commercial training courses in all aspects of Program and Project management and has been an Adjunct Professor for a number of universities.  Dr. Bojeun is currently an Adjunct Professor at Strayer University where he actively teaches business, logistics and project management courses for both undergraduate as well as graduate students. In addition, he provides motivational presentations to leaders throughout the world.

Contact Mark on LinkedIn or email at mark.bojeun@dc.gov

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on value chain mapping. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. Driving effective change requires an understanding of your organization’s value chain.

Upcoming Events

March 18
Agile Philly March Meeting:
I am speaking at Agile Philly’s March 18th meeting on the topic of Function Points. The meeting begins at 630 PM EST – 830 in King of Prussia, PA – Details at http://www.agilephilly.com/events/function-points

ISMA 9
I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.
More information

QAIQuest 2014
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

The Great Wall of China was a program.

The Great Wall of China was a program.

Scaling Agile project management to large, complex endeavors requires an Agile Program Manager to address the big picture coordination of programs.  Program management is the discipline of coordinating and managing large efforts comprised of a number of parallel and related projects. Scrum leverages a concept called the Scrum of Scrums to perform many of the activities need for program management.  Agile Program Management is not just repurposed project management or a part-time job for a Scrum Master.

Agile Program Managers coordinate and track expectations across all projects under the umbrella of the program, whether the projects are using Agile or not. Coordination includes activities like identifying and tracking dependencies, tracking risks and issues and communication. Coordination of the larger program generally requires developing a portfolio of moving parts at the epic or function level across all of the related projects (epics are large user stories that represent large concepts that will be broken down later). Agile Program Managers layer in each project’s release plans on top of the program portfolio to provide a platform for coordinated release planning. Techniques like Kanban can be used for tracking and visualizing the portfolio.  Visualization show how the epics or functions are progressing as they are developed and staged for delivery to the program’s customers.

Facilitating communication is one the roles of an Agile Program Managers. The Scrum of Scrums is the primary vehicle for ensuring communication.  The Scum of Scrums is a meeting of the all of the directly responsible individuals (DRIs) from each team in the program. The DRI has the responsibility to act as the conduit of information for his or his team to the Agile Program Manager and other DRIs. The DRI raises issues, risks, concerns and needs. In short, the DRI communicates to the team and the Scrum of Scrums. The Scrum of Scrums is best as a daily meeting of the DRIs chaired by the Agile Program Manager, however the frequency can be tailored to meet the project needs.  A pattern I have seen used to minimize overhead is varying the frequency of the Scrum of Scrums based on project risk.

Another set of activities that generally fall to the Agile Program Manager is the development and communication of program status information. Chairing high-level status meetings, such as those with sponsor or other guidance groups, is a natural extension of the role. However this requires the Agile Program Manager to act as a conduit of information by transferring knowledge from the Scrum of Scrums to the sponsors and back again. Any problem with information flow can potentially cause bad decisions and will affect the program.

We will explore the role of the Agile Program Manager in detail. For now, it is important to recognize that the Agile Program Management is more than a specialization within the realm of project management or a side job a Scrum Master can do in his or her spare time.  Agile Program Managers need to be well versed in both Agile techniques and in standard program management techniques because the Agile Program Manager is a hybrid from both camps. Agile Program Managers build the big picture view that a portfolio view of all of the related projects will deliver. They also must facilitate communication via the Scrum of Scrums and standard program status vehicles.  The Agile Program Manager many times must straddle the line between both the Agile and waterfall worlds.