Tuesday, June 27, 2017

Lean Software Development

Lean Software Development
Lean thinking is a business methodology that aims to provide a new way to think about how to organize human activities to deliver more benefits to society and value to individuals while eliminating waste. The term lean thinking was coined by James P. Womack and Daniel T. Jones, in their 1996 book with the same name, to capture the essence of their in-depth study of Toyota’s fabled Toyota Production System. Lean thinking is a new way of thinking any activity and seeing the waste inadvertently generated by the way the process is organized by focusing on the concepts of:

1. Value,
2. Value streams,
3. Flow,
4. Pull,
5. Perfection.

The aim of lean thinking is to create a lean enterprise, one that sustains growth by aligning customer satisfaction with employee satisfaction, and that offers innovative products or services profitably while minimizing unnecessary over-costs to customers, suppliers and the environment. The basic insight of lean thinking is that if you train every person to identify wasted time and effort in their own job and to better work together to improve processes by eliminating such waste, the resulting enterprise will deliver more value at less expense while developing every employee’s confidence, competence and ability to work with others.

The idea of lean thinking gained popularity in the business world and has evolved in two different directions:

1. Lean thinking converts who keep seeking to understand how to seek dynamic gains rather than static efficiencies. For this group of thinkers, lean thinking continuously evolves as they seek to better understand the possibilities of the way opened up by Toyota and have grasped the fact that the aim of continuous improvement is continuous improvement. Lean thinking as such is a movement of practitioners and writers who experiment and learn in different industries and conditions, to lean think any new activity.

2. Lean manufacturing adepts who have interpreted the term “lean” as a form of operational excellence and have turned to company programs aimed at taking costs out of processes. Lean activities are used to improve processes without ever challenging the underlying thinking, with powerful low-hanging fruit results but little hope of transforming the enterprise as a whole. This “corporate lean” approach is fundamentally opposed to the ideals of lean thinking, but has been taken up by a great number of large businesses seeking to cut their costs without challenging their fundamental management assumptions.

The essence of [the Toyota system] is that each individual employee is given the opportunity to find problems in his own way of working, to solve them, and to make improvements.
The above quote underscores a vital point because over the years there have been some ostensibly ‘lean’ promoters that reduced lean thinking to a mechanistic, superficial level of management tools such as Kanban and queue management. These derivative descriptions ignore the central message of the Toyota experts who stress that the essence of successful lean thinking is “building people, then building products” and a culture of “challenge the status quo” via continuous improvement.

Lean software development is a translation of lean thinking to the software development domain. The term lean software development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck. The book restates traditional lean principles, as well as a set of 22 tools and compares the tools to corresponding agile practices.

Lean software development can be summarized by the following nine principles, very close in concept to lean manufacturing principles:

1. Optimize the Whole
2. Eliminate Waste
3. Build Quality In
4. Deliver Fast
5. Defer Commitment
6. Create Knowledge
7. Empower People
8. Focus on Flow (of Value)
9. Continually Improve

Optimize the whole

Optimize the whole means
- to focus on the realization of business value
- take a systemic thought process.
- to take an holistic view.

Taking a systemic view means that one must attend look to the system within which people operate to understand why people are achieving the results they are.  Changing the system will help improve their results.  Effective results require good people and good systems.

The larger the system, the more organizations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships.

Systems thinking implies taking an holistic view since systems are more than the sum of their parts. This is one of the big differentiators of Lean and Agile. One must understand that the development team is only a part of the process.  Many of their challenges are due to upstream problems. If we can see the whole we can more easily change behavior of those upstream of the development team.

Eliminate waste

Eliminate waste by removing delays, only working on things of value that you know how to achieve and only starting work you know you can complete.  We must remove delays in our workflow because these literally create additional work to be done – redoing requirements, finding errors (while the fixing cost often stays the same, but finding bugs found late increases dramatically), integration errors (caused by the delays from when teams get out of synch until they are discovered in the integration process.

Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:

1. Building the wrong feature or product
2. Mismanaging the backlog
3. Rework
4. Unnecessarily complex solutions
5. Extraneous cognitive load
6. Psychological distress
7. Waiting/multitasking
8. Knowledge loss
9. Ineffective communication.

In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes like paperwork and features not often used by customers are waste. Switching people between tasks is waste. Waiting for other activities, teams, processes is waste. Motion required to complete work is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste. A value stream mapping technique is used to identify waste. The second step is to point out sources of waste and to eliminate them. Waste-removal should take place iteratively until even seemingly essential processes and procedures are liquidated.

Removing delays

Removing delays requires not working beyond the capacity of your teams as this injects delays into the workflow because people have to switch between projects and are often waiting for other people working on other projects. People often point to the cost of task-switching here, which, while considerable, pales in comparison to the additional work created by the delays themselves.

Build quality in

Build quality in means to avoid errors, not test them out.  Shortening feedback loops is a big help here.  In particular, the adoption of acceptance test-driven development is a method that virtually every team we’ve run across in the last dozen years would benefit from.

The customer needs to have an overall experience of the System. This is the so-called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, its price and how well it solves problems. Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness.

This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces – not in one vast chunk - preferably by face-to-face communication and not any written documentation. The information flow should be constant in both directions – from customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation.

One of the healthy ways towards integral architecture is refactoring. As more features are added to the original code base, the harder it becomes to add further improvements. Refactoring is about keeping simplicity, clarity, minimum number of features in the code. Repetitions in the code are signs of bad code designs and should be avoided.

The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests, having the same versioning, synchronization and semantics as the current state of the System. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customer expects it to. Automated tests are also considered part of the production process, and therefore if they do not add value they should be considered waste. Automated testing should not be a goal, but rather a means to an end, specifically the reduction of defects.

Deliver fast

Deliver fast is essentially the same as time to market.  Not a new concept.  But Lean adds the insight that if we focus on shortening the time of delivery by removing delays and focusing on quality, our productivity goes up and costs come down.  Quick delivery also allows for quick feedback and can help avoid building features that aren’t needed.

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. With speed, decisions can be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge.

Customers value rapid delivery of a quality product. The just-in-time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. Thus the work organization changes into self-pulling system – each morning during a stand-up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency of the process, which is also beneficial for team communication.

Defer commitment

Defer commitment means to make decisions when you have the right information yet always attend to the cost/risk of making decisions too early or too late.  Too many decisions are made too early. Deferring commitment requires taking steps so that delaying the commitment does not incur more risk while achieving better decisions when more information is available later.

As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments.

The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system. An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions. This does not mean that no planning should be involved – on the contrary, planning activities should be concentrated on the different options and adapting to the current situation, as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.

Create knowledge

Create knowledge means to create, capture, update and put to use the knowledge learned from product value.  Measure cycle time, work-in-progress, and which work-items have value.

Empower people

Empower people to make decisions which they are best able to make. Teams must be given clear boundaries within which to work, however. It also means to recognize the psychology of people. People are tribal, have a psychology that is sensitive (and averse) to significant change.  People also often identify with their work, so changing roles can be very difficult for them emotionally.
The lean approach follows the Agile Principle "find good people and let them do their own job", encouraging progress, catching errors, and removing impediments, but not micro-managing.

Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit.

Focus on flow 

Focus on the flow of value.  We accomplish this by managing our queues so workflows from concept to consumption smoothly.  Managing work-in-progress (WIP) is an effective way of doing this.  In particular, we must pay attention to delays, which literally increases the amount of work to be done.

Continually improve

Continually improve with a scientific method.  While software development appears complex, that is often because many of us have taken a simplistic approach.

Software development is a continuous learning process based on iterations when writing code. Software design is a problem-solving process involving the developers writing the code and what they have learned. Software value is measured in fitness for use and not in conformance to requirements. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input. The accumulation of defects should be prevented by running tests as soon as the code is written. The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing.

Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. During those short sessions, both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a customer is set-based development – this concentrates on communicating the constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialogue with the customer.

Read more…

Thursday, June 22, 2017

Agile Project Portfolio Management? Conclusion

Agile Project Portfolio Management
This is the last article in our Agile Project Portfolio Management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The following articles discussed demand management, categorization, evaluation, funding, alignment, authorization, and monitoring.

Whilst writing of these articles I read a lot of books and other articles about (Agile) project portfolio management. I have seen a number of different ideas and approaches and a number of Agile frameworks that touch the subject of portfolio management. For example SAFe and DAD.

The Disciplined Agile Consortium (creators of DAD) has defined a number of principles of Agile Portfolio Management where I can fully agree with.

Simplicity: Keep your approach lightweight and streamlined.

Value: Focus on value over cost.

Reduce Delay: Reduce the cost of delay [link].

Improve: Invest in streamlining the creation of value.

Stable Teams: Prefer stable teams over project teams.

Align to Value: Align teams to value streams.

Rolling Wave: Prefer rolling wave plans and budgets to annual ones [link].

Choice is Good: Support and enable diversity of approach.

Trust: Trust but verify.

Risk Driven: Govern by risk, not by artifacts.

Small is Good: Prefer small endeavors over large ones.

Quality: Invest in Quality.

Enterprise Aware: Optimize the whole.

But what I was missing was a simple blueprint that could be used as a base for implementing Agile project portfolio management. That is why I decided to write my own. This resulted in the Simple Portfolio Management Framework.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

You can buy my books The Art of Technology Project Portfolio Management and The Science of Technology Project Portfolio Management separate or as a bundle in my store. Just click here or on the image.
Buy The Art and Science of Technology Project Portfolio Management

Read more…

Saturday, June 17, 2017

Scaling Agile: Conclusion

This is the concluding article of our series on scaling Agile. In the previous articles we discussed the popular Agile scaling frameworks Nexus, DAD, LeSS, SAFe and Scrum at Scale. They all have many good ideas and parts that I like. Some are very prescriptive like SAFe, and others are the complete opposite, like DAD.

Personally, I am the opinion that the best strategy for scaling Agile is very depending on context like:

- How important is speed of delivery?
- How important is innovation?
- How important is team empowerment?
- Where are teams located?
- How agile is the organization already?
- How complex and/or tightly integrated is the product?
- What is the driving timeframe for becoming agile?
- How severe are the repercussions of a product defect?

We should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

Currently, the only scaling approach that really supports this kind of thinking is Scrum at Scale from Jeff Sutherland. His modular approach forces you to think about the different aspects of scaling Agile, and helps you create your own scaling strategy that suits you best.

Based on my experiences with scaling Agile at different companies and in wildly different contexts I am the opinion that the following guiding rules serve me well.

1. Do not scale, in most cases it is not necessary. Create well-defined product boundaries with interfaces and most scaling efforts are futile.

2. Do not multi-site. It makes simple things complex, and hard things even harder.

3. You cannot scale what you do not have, i.e. when you have no well-functioning Scrum teams in your organization you should not talk about scaling Scrum.

4. Think products, not projects. This shift in thinking will help organizations a lot in making better decisions.

5. Continuous improvement. Never stop learning, and do not be afraid to stop what is not working.

6. Technical excellence is important for agile teams, but for scaling it is essential.

7. Take a modular approach, there is no one size fits all framework.

8. You need top-down support, i.e. management wants to change their own way of working too.

9. Change the system, then culture and people's behavior will follow.

10. Tackle one product(group) at a time.

11. Feature teams, not component teams.

12. Empower your Product Owner (or similar role) to take the decisions he/she needs to be taking in that role.

13. Building is the easy part. You should think about operating your products as well. DevOps is the way to go.

Other articles in this series:

1. Scaling Agile: Nexus Framework
2. Scaling Agile: DAD 
3. Scaling Agile: LeSS
4. Scaling Agile: SAFe
5. Scaling Agile: Scrum at Scale
6. Scaling Agile: Conclusion

Read more…

Thursday, June 15, 2017

Agnostic Agile

As experienced agile practitioners and as people responsible for agile change and transformation, we should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

We should take this very seriously. Our work is to help our clients attain the right level of agility that meets their needs, our work is not to create framework lock-ins nor to limit how agility can be applied to the organization, whether at team levels or at scale.

This means we as agile practitioners must strive to be masters of our craft, understand and practice at least two formally established frameworks or methods, uphold good conduct between ourselves and others, and help to nurture and grow our community of agile practitioners.

Sam Zawadi created an initiative to spread this important message. The Agnostic Agile Oath. This oath is a manifestation of these intentions, distilled succinctly into a simple list of agreements. Go check it out, and sign when you agree.

Read more…

Saturday, June 10, 2017

Agile Project Portfolio Management? How to monitor your portfolio

Agile Project Portfolio Management
This is the eighth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The following articles discussed demand management, categorization, evaluation, funding, and alignment. The previous article was about portfolio authorization and the role of the Portfolio Owner. This article is about monitoring your portfolio.

We already discussed the need for some information at the project proposal phase in our article about demand management, but at the latest in the evaluation and alignment phase of the portfolio management process it becomes clear that we need information about ongoing projects in our portfolio in order to make informed decisions about these projects and the portfolio as a whole.
Anything that can be measured can be improved. However, organizations don’t always do sufficient monitoring. Few organizations actually track project and portfolio performance against benchmarks. Worse, strategic multiyear initiatives are the least likely to be tracked in a quantitative, objective manner. For smaller organizations, the absence of such a process might be understandable, but for a large organization, this is a must.

Not monitoring project results create a vicious circle: If results are not tracked, then how can the portfolio management and strategic planning process have credibility? It is likely that it doesn’t, and over time, the risk is that estimates are used more as a means of making a project appear worthy of funding than as a mechanism for robust estimation of future results. Without tracking, there is no mechanism to make sure initial estimates of costs and benefits are realistic. 

This is crucial because there can be a tendency to provide cost estimates that are artificially low in order to gain project approval, especially where there is no monitoring process in place to capture this. What’s to stop the winner’s curse of the most inflated projections getting funded based on elaborate but dubious projections, rather than the best project with credible and realizable, if more modest, strategic benefit? If you are not monitoring performance, then not only will execution performance inevitably deteriorate but your selection process will lose legitimacy and will ultimately become a time-consuming charade. 

Project Metrics

In my opinion, the minimal set of metrics that should be monitored for each project in execution are:

- Estimated end date (for resource allocation)
- Costs till date (exact number)
- Expected costs till finish (rough estimation)
- Remaining budget (exact number)
- Delivered value since last status update (YES/NO question)
- Expected gain on investment
- Risks
- Issues
- Allocated resources 

Depending on your company and project you can use additional metrics like:

- Employee / Project Member satisfaction
- Stakeholder satisfaction
- Customer satisfaction
- Quality delivered to customer
- Time to market
- Return on Investment
- Meeting business case objectives
- Customer adoption
- Meeting governance criteria
- Benefits realization

When you look at this list of metrics you will notice that none of the typical Scrum project metrics like Technical Debt, Retrospective Items or Velocity are listed. This is because those metrics measure the quality of the Scrum process and are focused on improving Scrum teams. They do not say anything about the success of the project itself. When defining your own organization's metrics it very important to make this difference. What you can also see is that none of the metrics is Scrum specific. Nor specific for Waterfall or any other method. 

Monitoring needs to be balanced. Not monitoring project success can cause sloppy execution, which is costly. However, monitoring too much can cause a project to drown under the weight of its own status updates. Collect data frequently, but only at the level required to make a decision. 

Budgeting is one example. It is important to define what constitutes a meaningful budget overrun and measure to that level. If you only care about the aggregate budget, then breaking out the full budget by line item on a monthly basis is overkill and can distract from the decision and monitoring process that you’re trying to follow. Where data collection is not automated, track only what you intend to act on; more detail can always be captured subsequently should an issue arise (see Exception Based Reviewing)


Reporting is critical to an effective project portfolio management system. Whereas collecting up-to-date and accurate data is a challenge, building an effective reporting system is relatively easy. Reports should answer specific questions and be tied to specific processes. Reports that simply look appealing or provide a host of data without underlying meaning are ineffective. Therefore, reports should be the outcome of your project portfolio management processes. It is important to consider the following key report types: 

Single-page project report: Using a consistent format for project status reports is important. Doing so means less time can be spent on the layout and more attention can be paid to the data within the report. Each project summary should be contained on a single page or screen, with top-level details and the contact information for the project manager and project owner provided should questions arise. The data should also be time-stamped. 

Financial information: This provides aggregate roll-up on budget and costs across projects with the ability to drill-down into individual projects. 

Project dashboard: One-line summaries of the projects currently in execution, filterable by important grouping such as division or project sponsor (see Categorization). Often these lists can run to thousands of projects, so by default, filter on the poorly performing projects (such as no value delivered on the status indicator) first, as it is likely those projects are of most interest and require the most attention. 

Resource allocation view: This is a view of current resource availability and utilization for the coming 12 months. This means people, machines, money, and anything else that could be a bottleneck in realizing your projects. 

Strategic alignment: This provides a view of the strategic goals of the business and how the current projects contribute to them. 

Flexible pivot table capabilities: No project report or set of reports will capture everything that is needed, even where drill-down capabilities are available. Using a drag-and-drop pivot table-style analysis on the inventory of projects or proposals can help executives and others find the information that they need to answer a particular question and also lead to creative analysis to produce new report types to further support decision making.

Creating an effective dashboard

Once you know what you are looking to measure, it helps to create an on-screen dashboard that captures the relevant information. The term dashboard uses an automotive analogy to convey the ideas of getting all relevant information simply summarized in one place. This gives an opportunity to effectively summarize project data in an attractive and transparent fashion. Usage of color and graphical indicators can highlight areas of importance, and the best dashboards combine current and trend information to identify patterns. 

Online dashboards can also be created to enable drilling down so that the summary data are presented but if more information is needed, the user can double-click on a project to see full detail on risks, issues, budget, the project manager, team, and current tasks. This type of drill-down setup helps to ensure that the initial dashboard is concise but the information is all easily accessible when needed. See for example the Office 365 Project Portfolio Dashboard below.

Project Portfolio Monitoring Dashboard

Not all dashboard metrics need to be quantitative. Team morale is often hard to define and cannot easily be pulled from a reporting system like the most recent cost data, but it is important and can be very useful in monitoring how the portfolio is progressing. Ensuring that the right data are captured on a dashboard is critical, regardless of whether that data can be pulled out of a database. 

Also, with broad survey technology, it does become easier to leverage the wisdom of crowds across the project team. No one individual or data point may be the single source of truth on the morale of project team, but by anonymously surveying the project team and aggregating the results, team morale can be tracked on an ongoing basis. Technology makes the collecting of this sort of data increasingly simple.


Often, organizations lock down the permissions or access rights that are given to their employees too finely. Security is based on minimizing the negative consequences of information leakage, rather than maximizing the positive benefits of information sharing within the organization among employees. Consider making various project key performance indicators (KPIs) public to a broad set of employees within the organization. This will help foster new ideas for projects and improve project collaboration. 

Ideally, disclosure at the KPI level should not reveal confidential information and more granular permissions can be set on drill-down financials (like individual wages and rates for external consultants). Generally, providing more information on project performance and processes can help with the goal of avoiding duplication of effort, and provide a further opportunity to emphasize the goals of the organization. 

Portfolio Review Meetings

The Portfolio Owner will schedule regular (I recommend monthly) portfolio review meetings. Participants in these meeting are the Portfolio Owner, Portfolio Committee and invited guests (for example the Product Owner of a large initiative to give a detailed update).

This monthly portfolio review meeting helps make the collection of data actionable. The meeting can review the dashboard, and particularly any significant changes related to the dashboard, and help address them. Knowing that the dashboard will be used in this way makes the dashboard meaningful. Simply creating a well-designed dashboard in the hope that someone will find and act on it is wishful thinking if there is no process to support it. 

Ahead of creating the dashboard, consider decision thresholds and the resulting actions. If an indicator turns red for a particular project, what would be the result? If no action would be taken, then why is that piece of information on the dashboard? If the resulting decision is ambiguous, then clarifying the course of action ahead of time can be enormously helpful, given that making decisions at the moment can become a lot more heated. It is also important to consider what other information could result in portfolio actions being taken. If the information is material, consider adding it to the dashboard, even if the data in question are not quantitative. For example, project management might have a perception of project performance. 

Ideally, the dashboard should capture all aspects of project status. If a project could be killed despite having a completely positive dashboard performance, then either the dashboard or the organization is not working effectively.

Exception-based reviewing

It may not be necessary to go into detail on all projects, but ensure that those projects in the portfolio that are not delivering the expected value are followed up on. A process that includes all projects but only invests significant time in those projects that are off target is exception-based reviewing. Exception-based reviewing means that only projects that pass a certain threshold are reviewed. For example, projects that are more than 10 percent over budget, or are not delivering value for over two months, are highlighted and require a decision as to whether corrective action is needed. This saves time in not having to review all projects in a detailed manner, as the projects that are on track are not analyzed to the same level of detail. It also means that attention can be drawn to projects when problems occur, not necessarily when the review meeting happens. 

Having alerts set up should a project go off target means that stakeholders can be notified in real-time, rather than having to check the dashboard or waiting to receive the data within a particular review meeting. This can improve the speed of response, which can help drive more agility in portfolio management. It also creates a feedback loop, which can help drive improvement. Driving the process by alerts rather than by scheduled meetings can be helpful, even if the review meeting is monthly, if a project starts to go off target the day after the review meeting. By the time of the next review meeting, it might be a month behind schedule, which for a six-month project likely means the project has severe issues. 

Alerts also work well for the late stages of projects—as delivery is close, more monitoring attention is often needed, and alerts can be configured to support that, without requiring the need to scrutinize all projects in detail as they approach delivery. An efficient system of alerts ensures that management focuses on the right issues systematically, rather than spreading themselves too thinly across the whole portfolio.

Our next article will conclude this series. It will define Agile Project Portfolio Management as we have discussed in the last nine articles. It's advantages and disadvantages, implementation challenges and opportunities.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

You can buy my books The Art of Technology Project Portfolio Management and The Science of Technology Project Portfolio Management separate or as a bundle in my store. Just click here or on the image.
Buy The Art and Science of Technology Project Portfolio Management

Read more…