This article was first published by Scrum Alliance on July 22, 2013.
During the last few years, my view of how programs work has evolved. It has moved from viewing program management as traditional "old-school" handling of multiple projects and product portfolios (dry and boring) to seeing program management as a key to ensuring organization success that aligns the organization with its vision, strategy, and innovation. I think of program management as a crucial tool that makes an organization successful by pointing its entire energy and focus toward its most important initiatives and fulfilling its promise to customers, shareholders, and employees.
Why do organizations need programs?
"Programs are a group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually," according to PMI. What do organizations have to gain by investing in coordinating and controlling multiple projects as a program? This is similar to asking what value program management brings to an organization.
A quick search on Google reveals various links on the topic. An article at chron.com lists the following: comprehensive view, work toward strategic goals, consistency, cost savings. An article at eHow.com lists supervision, organization, budgeting, funding, accountability, and delegation.
Program managers shepherd different teams and projects in the organization toward a common objective. These teams sometimes have different internal priorities, which can impact when and how they deliver their part of the program. Program managers help surface these issues and facilitate much-needed conversation around issues, risks, and mitigation to achieve a higher-level organizational goal (or a set of goals).
Streamlining various lines of work within the organization can translate into several financial and nonfinancial benefits, such as revenue generation through on-time market launches, avoided or reduced opportunity costs, reduced operational costs, higher customer goodwill and revenue retention, transparency, and even better employee engagement.
Simple or complex?
There are many factors that make programs simple or complex to execute, such as:
· Number of projects
· Dependencies
· Size of project teams
· Resource availability/capacity
· Prioritization of the initiative
· Degree to which roles and responsibilities of project teams are well defined
· Communication flows between project teams that require less coordination
· Processes followed by project teams
· Degree of transparency between the teams
· Silos within the organization
The world of strategic program management is usually complex. Simple programs are hard to find, unless you are a small organization with a tightly knit set of teams and only one or two objectives to work on. The reality is that things start becoming complex even in small or midsized organizations when there are multiple issues at play.
How does complexity impact programs?
As organizations grow in size, they usually spread their operations, increase the number of their product offerings, try to become more cost efficient, and create specialized units for different functional areas (marketing, finance, sales, legal, engineering, technical operations, customer support and service, business intelligence, etc.). This suggests that organizations should pay attention to their most important goals while structuring their programs. That can be difficult, as different functional groups of the organization may be working on multiple priorities that might be competing with each other.
How do Agile principles help in dealing with complexity?
Principles laid down along with the Agile Manifesto can be useful in addressing issues related to complexity of programs. Even though these principles are heavily colored with nuances of software development, they can be applied in addressing issues related to complex program management:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Organizations usually have a strategy that is supposed to convey to its employees what is most important for its success in the coming period. This strategy usually includes what the leadership sees as most valuable to its customers. Organizations that manage successful programs are able to prioritize those programs as per their strategy and focus their energy into those initiatives that are most important to their customers.
2. We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage: Just as with software development teams using the Agile process, it is desirable that the rest of the teams are attuned to changing market conditions or new insights (whether external or internal to the organization) that might require the product or a service to take a different direction than initially conceived. If all teams are receptive to change, there is a greater chance that the needs of customers will remain the central focus.
3. We deliver working software frequently, from every couple of weeks to every couple of months, with a preference for the shorter timescale. Just as Agile software development teams manage their work, such as working on small chunks, it makes sense for program teams to show off their work in short cycles so that the rest of the organization knows how the entire effort is progressing. Examples include iterations on sales and marketing strategy by the sales and marketing teams, iterations on customer communication/rollout planning by relevant teams, iterations on a new product or major functionality by the development teams.
4. Businesspeople and developers must work together daily throughout the project. There is great value in understanding the business perspective while building software. The same is true for other functional groups within the organization, who may not be as involved in building the software as they are in maintaining it. If the development itself is complicated and there are multiple development teams involved, it becomes even more important to keep everyone aligned with business expectations so that the program progresses in the right direction.
5. We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done: All teams involved in a strategic initiative need to be motivated to deliver as per customer needs. If the environment encourages favoritism instead of making decisions based on merit, there are chances that everyone will not give their best to fulfill the goal of the program, likely impacting it adversely.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face-to-face communication impacts teams' effectiveness by helping them build rapport and find solutions to bottlenecks and problems quickly. This is true for programs, even though it is much simpler to institutionalize daily face-to-face communication for a co-located team of five to seven people who are working on a single objective. While this is true, program teams should synchronize as often as they can and use technology to fill the gaps if they are not co-located.
7. Working software is the primary measure of progress. This principle is most useful in complicated projects involving multiple software development teams. Even when other nondevelopment teams are involved in a program, software development is often on the critical path, and that is often where most of the costs are incurred. So it makes sense to measure and track the progress made on working software. Likewise, program teams should measure and track progress of other non-software development deliverables that are required for readiness to deliver the product or service to the end users (launch readiness).
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. From the program management perspective, all teams should maintain and deliver at a pace based on the work needed to satisfy the program objective. In many situations, one team might start its work after another team has delivered. For example, the team in charge of invoicing may only be able to update the boilerplate of a product after that product is ready and the legal team has delivered the boilerplate to them. Dependencies such as this need to be tackled by program managers, along with the teams, when planning cross-team programs. When program management is sustainable, dependencies surface regularly and are addressed routinely -- kind of like the way it works within a small Scrum team, where those dependencies surface and are resolved on a daily basis.
9. Continuous attention to technical excellence and good design enhances agility. There is a balance between doing the right things and doing things right. When in a rush, teams may be tempted to cut corners in order to deliver on time. Sometimes this tendency might be driven by a business need that cannot be overruled, and teams are forced to take shortcuts. When this happens, teams must identify and track this as debt that they need to repay at a later stage (sooner is better, as with any debt that incurs an interest cost). Repaying debt regularly and doing things right ensures that the team does not slow down (or become bankrupt!).
10. Simplicity -- the art of maximizing the amount of work not done -- is essential. Even in case of complex programs, organizations should strive for simplicity. Transparency and visibility are needed in order to create simplicity and maintain the flow of work between teams.
11. The best architectures, requirements, and designs emerge from self-organizing teams. Agile encourages self-organization, which can be useful when managing programs. For multiple teams, this starts to happen when the each team is considered a unit and the overarching program team is considered the team that needs to reorganize. This is a question of mind-set and is in some ways easier to understand in case of small teams. When multiple teams are involved and each of them has slightly different (at times divergent) goals, self-organization can be difficult to achieve. That is where transparency, prioritization, and visibility of organizational objectives to all teams are useful.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Inspecting and adapting at regular intervals is necessary to re-enforce good practices and make improvements. Agile encourages teams to practice self-sustained introspection and retrospectives. This is an important tool for program teams to review and use to fine-tune their practices for long-term success.
Summary
Agile principles, though exhibiting an overlay of software development influences, can be valuable for managing programs involving multiple teams from diverse functional groups.
No comments:
Post a Comment