Foundational Principles
| MSF foundational principles are guiding concepts for how a project team should work together to deliver a solution. These principles should be internalized by each team member and applied in how members operate together as a team. These principles also apply to how a team should work with their organization and with stakeholders. At the core of MSF are nine foundational principles:
The following sections provide practical insight on some seemingly commonsense principles. Together, these principles express the MSF philosophy, forming the basis of a coherent approach to organizing people and processes for projects undertaken to deliver solutions. They underlie both the structure and application of MSF. Although each principle has been shown to have merit on its own, many are interdependent in the sense that the application of one supports the successful application of another. When applied in tandem, they create a strong foundation that enables MSF to work well in a wide range of projects that vary in size, complexity, and type. Foster Open CommunicationsIt seems obvious that any project team ought to share information. What is not so obvious is that for a team to be effective and efficient, an appropriate level of information needs to be shared among team members and across the enterprise. A team needs to understand the nature of what needs to be done and how team members and external folks communicate. The hard part is determining an appropriate level for each relationship and what information needs to be shared. For example, should you share the same level of information with an executive as you would share with a team member? Not likely. Nor would that executive likely have the time or patience to appreciate you going to that level. Too many times people confuse flooding someone with data as being the same as sharing information. Where "open" communications comes into play is twofold. First, it involves sharing the plain truth, and not some slanted spin on information because a sender is fearful that a receiver cannot handle the truth, does not want to hear the truth, or will take punitive action. If an organization establishes an open communications environment, everyone will be better able to adjust plans accordingly. The second aspect of open communications is that all project information has to be readily available and, more important, actively shared. For instance, open communications is not just making completed deliverables available for others to read in some dark corner of a collaboration site. Open communications is making sure a team knows enough about what each member is working on and knows when they can expect a deliverable or a draft of the deliverable for their review and comment (well before it is due). This could be a challenge because some people do not like to share work before it is done. Worse yet, some still perceive information and knowledge as power and share as little as possible. This "need to know" model of restrictive communications is very counterproductive, especially as the size and complexity of a project team grow. Open communications is a lofty goal and often culturally very hard to foster. Keep in mind that if not handled correctly, open communications could be very detrimental to a project. It is like drinking from an informational fire hose with the obvious risk that someone drowns in all that information and is less efficient and effective. Accordingly, open communications does not mean flooding team members with e-mail messages and writing treatise-sized documents. Conversely, open and inclusive communications means sharing just enough information with the current team, and subsequent team(s), to increase their understanding and reduce wasted efforts. An obvious challenge is continually determining what amount of information to share with the various team members and stakeholders. Open Communications in MSFAs challenging as it might be for logistical, practical, and cultural reasons, MSF encourages being as open and inclusive as possible with communications, both within a team and with key stakeholders. When used throughout an entire project life cycle, open communications fosters active customer, user, and operations involvement. Communication becomes a medium through which a shared vision and performance goals are established, measured, and achieved. When personalizing and adapting MSF to fit a team's needs, it is necessary to understand what needs to be communicated, when, and at what level of detail. To help facilitate this, the MSF Team Model is structured to support open communications. The MSF Risk Model is structured to openly handle project risks. The MSF Governance Model fosters open communications through incorporation of key checkpoints. Work Toward a Shared VisionEvery day so many decisions are made at all levels of a project that, unless everyone shares a common vision, quick resolution of decisions could be burdensome and overwhelming. Having a shared vision empowers team members and enables agility so that team members are able to make informed decisions quickly in the context of achieving a vision. A shared vision also helps team members fill requirements gaps as they are discovered. Sometimes when a team is stuck in the present, a vision can provide motivation and hope for the future. But what is a vision? In business terms, it is a concise description of the overall mission. It provides clear and quantifiable goals without biasing or constraining how they will be accomplished. Typically, this vision goes beyond the current project to paint a long-term and unbounded understanding of what the team is trying to accomplish. A vision is usually held at a solution level where it might take a few projects to deliver on that vision. Conversely, the realization of a vision through a solution definition might need to be decomposed into many projects. Why is a shared vision so important? When all participants understand a shared vision and are working toward it, they align their own decisions and priorities with a broader team purpose represented by that vision. Without a shared vision, team members and stakeholders might have conflicting views of a project's direction, goals, and purpose and be unable to act as a cohesive group. An unaligned effort is wasteful and potentially debilitating to a team. Teams often fail to understand that even if they think they successfully delivered a requested solution, without a shared vision, stakeholders might not agree with their assessment. Without a unifying shared vision, it is extremely challenging to measure tactical execution because it depends on which variation of a strategic vision a team is being measured against. Shared Vision in MSFClarifying and getting commitment to a shared vision are so important that it is the primary objective at the beginning of any MSF project. Working toward a shared vision requires the application of many of the other principles that are essential to team success. Principles of empowerment, accountability, communication, and delivering business value each play a part in successful pursuit of a shared vision, which can be difficult and courageous workwork that often needs leadership and personal fortitude. A shared vision comes into play with the MSF Governance Model. The iterative nature of the MSF Governance Model means that many parts of a solution could be in various stages of completion. To support this approach, a shared vision is required to guide concurrent delivery of these parts toward one coherent and integrated solution. Without a shared vision, the likely impact is that the later stages of delivery will need more, unplanned effort to pull together and integrate the disjointed parts. The MSF Team Model has all roles (described in Chapter 4, "Building an MSF Team") represented from the beginning of a project. With each role represented, the process of creating shared vision helps to clarify goals and bring conflicts and mistaken assumptions to light so they can be resolved. Once agreed upon, a vision motivates a team and helps to ensure that all efforts are aligned with project goals. It also provides a way to measure success. Empower Team Members
How often are you on a project where everything is clearly mapped out and not likely to change? Odds are...not often. Empowering teams is one of many ways not only to survive in this type of ever-changing environment, but also to enable team members to creatively find ways to be successful. Lack of empowerment not only diminishes creativity but also reduces morale and thwarts the ability to create high-performance teams. Like many of these principles, "empower team members" is a catchy phrase that companies like to espouse but often have limited success in truly achieving. Having an environment that supports empowering team members is summed up in a couple of questions: Does an organization truly trust a project team to make the right decisions for a project? Do team members trust each other? Often team members understand their own area and are able to make good decisions for their area but feel limited in their ability to make good decisions that have effects beyond their area (i.e., think global, act local). If team members feel empowered, responsible for the whole solution, and have a shared vision, there is a greater chance they will make good project-level decisions. And as discussed in the section titled "Work Toward a Shared Vision" earlier in this chapter, to be agile, team members must be empowered to make decisions given the vast number of decisions that must be made every day. Empowering team members means there is a level of trust that all team members will deliver on their commitments. Likewise, stakeholders are able to empower and trust the team. Building a culture that supports and nourishes empowered teams is challenging and requires steadfast support by an organization. It also includes creating an environment so that team members feel safe taking reasonable risks (referred to as personal safety). If done successfully, empowerment engenders more confidence in a team and its abilities. For example, with open communications about roles and responsibilities, project management should be more at ease with greater degrees of empowerment. If they clearly know what is expected of them, most people are able to rise to most challenges and deliver quality solutions. With trust and empowerment comes a benefit of being able to rechannel efforts into delivering a better quality solution as opposed to monitoring and policing team members. That is not to say there should be no monitoring, just that heavy-handed, burdensome, and bureaucratic activities should wane as empowerment is successfully instituted. Empowering team members must be done in a thoughtful way to help bring along those that are not ready for empowerment. A body of research can be used in assessing how ready team members are for empowerment (i.e., situational leadership).[1] Although positioned as advice to leaders, this research involves how to better understand team members and subsequently how team leads might appropriately interact with other members on various tasks. As such, in assessing how ready team members are for empowerment (i.e., empowerment readiness), it is helpful to consider how much tasking and encouragement each team member requires.
Empowering Team Members in MSFEmpowerment has a profound impact on MSF. The MSF Team Model is based on the concept of empowered equals (i.e., team of peers). People and organizations outside of a team also need to empower and trust team members to make good decisions in light of a shared vision. This helps to eliminate the two extremes commonly found on teams: (1) relying on the "boss" to make hierarchical-based decisions, and (2) decision by committee, which often leads to analysis paralysis. MSF advocates empowering team members to help with their productivity and ability to remain agile while expecting change. Establish Clear Accountability and Shared ResponsibilityEmpowered team members often feel more accountable for their decisions and willing to be jointly responsible for a project. More team member accountability leads to higher quality. For example, if a team member represents that he or she has completed a task but it is found not to be at the right level of quality, that team member is responsible for completing tasks to stated quality levels. To not make this punitive, every team member shares responsibility for the overall solution and its deliverables. This fosters stronger members of a team to be motivated to help bring along others. For example, if one part of a solution lacks sufficient quality or is delayed in delivery, the whole project team assumes responsibility; should one team member fail to deliver, the team fails to deliver (it's an "all for one and one for all" mentality). Accountability and Responsibility in MSFMuch of what is espoused here is based on team members being sufficiently self-motivated to be accountable and responsible. When first adopting MSF, this is not often the case, and as such, more governance is needed. Keep in mind that this is exactly opposite the spirit of MSF. However, as a team successfully adopts MSF, individual accountability coupled with empowerment is a good goal to work toward. Because MSF structures a team to be an interdependent network rather than a hierarchy, team members are jointly responsible for overall management of a project. This is not to imply that shared responsibility for managing a project negates the need for a project manager role. What it does mean, as discussed later, is that everyone is empowered to manage proactively all aspects of their portion of a solution, and to share in assuming a project is successful. A project manager role has specific responsibilities in contributing to that success but is not the "boss." Deliver Incremental Value
There are two facets to delivering incremental value. The first involves making sure what is delivered has optimal value to stakeholders. The second facet involves determining optimal increments in which to deliver value (i.e., frequency of delivery). Classically, solutions are defined from requirements, decomposed into a collection of work packages, which in turn are assembled into schedules to accomplish that work based on the capability of a team and project constraints. Although there is nothing wrong with that approach, it sometimes appears that a disconnect exists between requirement gatherers and a delivery team when it comes to understanding what value is contained within work packages. Because delivery of value is determined by stakeholders, requirement gatherers are better positioned to understand intrinsic value. All groups (requirement gathers, delivery team, and stakeholders) need to work together to make sure each work package contains the maximum possible amount of high-value components of a solution. To mitigate the disconnect about what is high value (given it often changes over time), a variation of this approach is to make sure that work packages are small enough such that a clear, quantifiable understanding of the value contained within each work package exists. This short-cycle, iterative approach provides more frequent opportunities to validate with stakeholders that what is being delivered has value. This enables a team to focus on incrementally and continuously delivering high value to the customer(s), not burning down resources and the schedule by delivering mixed-value work packages. Also, smaller work packages usually translate into smaller batches of risks and issues to monitor and resolve. Hence, often it is easier to deliver incrementally. Therefore, completing small, cohesive work packages provides a progressive flow of quantifiable value to the customer(s) at regular intervals, as opposed to less frequent delivery of larger work packages that contain mixed levels of value (often referred to as earned value: "The value of completed work expressed in terms of the approved budget assigned to that work for a schedule activity or work breakdown structure component"[4]).
The second facet of delivering incremental value centers around determining how frequently a team should deliver. The answer is project specific and lies in the balance between the cost to prepare and deliver a solution versus benefits gained with frequent delivery. The cost to prepare and deliver a shippable solution is measurable. It is the amount of tangible disruption of a project team. For example, a team might need to address issues as part of a solution stabilization and deployment effort, whereas these issues might have been worked out as part of the regular course of development in a longer iteration (i.e., net-net: issues were resolved at a much higher cost to a project because they needed to be resolved sooner as part of stabilization instead of being addressed in development). A key benefit gained with frequent delivery is that nothing is more motivating than seeing a solution come together and start to take shape. It gives everyone a better understanding of realized value contained within a solution. Team members who did not quite grasp a shared vision then start to see a tangible solution. Skeptical sponsors are able to "touch" a solution, are reassured that a return on their investment is starting to be realized, and are able to provide more concrete feedback as to how a solution satisfies their needs and expectations. In addition, architects who formed a vision start to share with others tangible evidence of that vision. It also benefits those roles that depend on early and frequent delivery to accomplish and progress or advance their work. It provides them with a snapshot of a solution that is not too out of phase with the solution being developed. For instance, deployment and operations teams need something as soon as possible to start refining their plans and activities. If a solution is not available until the end of a build track, odds are that deployment issues will appear. A side benefit is that by making deployment a habit and by practicing and testing deployment procedures, even with early solution prototypes, the costs to prepare and deliver a solution are reduced because the whole team learns how to make deployments run smoothly and predictably. Additional benefits of institutionalizing frequent delivery as soon in a life cycle as possible include the following:
Delivering Incremental Value in MSFIf it makes sense to deliver incremental value, why do teams sometimes deliver large blocks of questionable value? Why do they sometimes leave integration of solution componentsoften the ones necessary to realize valueuntil the end? MSF avoids this by guiding teams to make frequent deliveries of incremental value, even though a solution might not be functionally complete. MSF uses its two models to drive incremental delivery of value: Governance Model and Team Model. The MSF Governance Model is structured to support frequent and iterative development and deployment. The MSF Team Model is structured to make sure that all aspects of what is being delivering are of high value. Combined, these models enable a team to deliver value quickly and incrementally for stakeholder review. To help understand and quantify value, a team needs to be customer focused. Being "customer focused" is another one of those catchy phrases that people and organizations banter around. But what does it really mean on a day-to-day basis to be customer focused? From a mechanical perspective, being customer focused is being able to trace each activity, deliverable, and feature back to a customer or user requirement. However, within MSF being customer focused is much more. The MSF Governance Model combined with the MSF Team Model enables a feedback loop to convey cost implications of delivering value. Because MSF is flexible and adaptable, should the costs of delivering incremental value start to outweigh the benefits, the process easily can be adjusted to rebalance the return on investment. Stay Agile, Expect and Adapt to Change
Because change happens often, and usually at the worst possible moment, having an agile way to handle change means that the common disruptions caused by change are often minimized. Staying agile means an organization is ready for change and is able to smoothly adapt and adjust. As discussed later, one of the best ways to handle change is to have a good understanding of project constraint prioritizations and have a process that quickly considers and assesses what to do regarding the change. For example, if a change surfaces, its impact is assessed and rational steps are taken to adjust project activities accordingly. Although change happens, an effective change control process throttles the amount of change to enable a team to optimize their productivity and creativity. Relating magnitude of change with team agility (i.e., their capacity to handle change) provides an understanding of how productive and creative a team likely will be. For example, as depicted in Figure 3-2, a team with low agility likely will have rapidly decreasing productivity as the volume of change increases (1). Conversely, a team with high agility likely will not incur a significant decrease in productivity as the volume of change increases (2). Figure 3-3 relates the amount of change to team member creativity. A team likely will realize an increase in creativity as change increases, but there is a turning point at which a team becomes overloaded with change (3) and additional change starts to deteriorate team dynamics, causing a reduction of creativity (4). Figure 3-2. Relating team productivity to magnitude of change and team agility Figure 3-3. Relating team creativity to magnitude of change Agility in MSFAlthough MSF has little to no influence over whether change happens, MSF does provide an orderly, measured, and agile means to handle change when it does occur. Through open communications and empowerment, MSF enables teams to be agile and to act on change. MSF has designed both its Team and Governance Models to anticipate and manage change. The MSF Team Model fosters agility for teams to address new challenges by involving all team roles in key decisions, thus ensuring that issues are explored and reviewed from all critical perspectives. In addition to changes coming from external origins, project teams should expect changes from stakeholders and even from within a team itself. For instance, teams must recognize that project requirements can be difficult to articulate at the outset and often will undergo significant modifications as possibilities become clearer to participants. The MSF Governance Model, through its iterative approach to building project deliverables, provides a clear picture of deliverable status at each progressive stage. It enables stakeholders and team members to identify and respond to change effectively. This minimizes negative effects and disruptions caused by change while optimizing any benefits. Invest in Quality
How tolerant are end users of quirky behavior or, worse yet, partial working solutions? Will they be patient with unexpected behavior? If a solution involves finances, is it acceptable to "misplace" or "find" a few dollars? Many organizations espouse quality, often a loosely defined term, but lack the understanding of how to quantify quality. Solutions that involve infrastructure operations are usually more mature in this area. Typically, they have established agreements such as Service Level Agreements (SLAs) that specify quality in measurable terms. For instance, a vendor providing a messaging service can be nonoperational for only up to 15 minutes a month. Often, this is phrased as: "How many 9s are needed?" A service that is available for three 9s, for instance, would be operational 99.9 percent of the time. Quality, or lack thereof, is defined in many ways. Quality can be seen simply as a direct reflection of the stability of a solution, something achieved through consistent process, or can be viewed as a complex trade-off of delivery, cost, and functionality. Quality must be quantified, defined, and planned. It does not happen accidentally. It requires investment of time and resources. It involves a mix of prevention and verification. Efforts need to be explicitly applied to ensure that quality is embedded in all solutions and services that an organization delivers. Organizations sometimes make a mistake of demanding the "highest-quality solutions" from their delivery teams. This request is dangerous because, unless explicitly defined, a team might understand this to mean five 9s or better (i.e., five 9s equates to about five minutes per year of downtimetypically very costly to achieve). An organization should avoid unnecessarily driving up the cost of delivering a solution as a result of excessive quality. Each organization should understand what the right level of quality is for all aspects of a solutionfrom software components to user manuals. Most important, thinking about what the right levels of quality are encourages teams and individuals to develop a mindset centered on quality improvement. Quality improvement is everyone's business, every day. The idea of quality improvement complements the basic human desires of taking pride in your work, learning, continuous improvement, and empowerment. An investment in quality therefore becomes an investment in people, as well as in processes and tools. Successful quality management programs recognize this and incorporate quality into the culture of an organization. They all emphasize the need to invest continually in quality because quality expectations typically increase over time. Standing still is not a viable option. Entire industries have evolved out of the pursuit of quality, as witnessed by the multitude of books, classes, theories, and approaches to managing quality (i.e., quality control) as well as monitoring quality (i.e., quality assurance). Promoting quality involves a continual investment in processes, tools, and training. Efforts to improve quality include a defined process for building quality into solutions and services through deliberate evaluation and assessment of outcomes (i.e., measurement). Enabling these processes with measurement tools strengthens them by developing structure and consistency. However, an organization and/or a team can overrely on measurements rather than retain a holistic quality perspective. Measurements should be one of many indicators of quality. If an organization or a team relies too much on metrics, team members might start to focus myopically on metrics and potentially skew them. The result is that these skewed metrics give others a false sense of solution quality.
Investing in Quality in MSFFacilitating quality underlies every aspect of MSF. MSF tries to bolster an increase in quality through a set of natural checks and balances in its Team, Governance, and Risk Models. Team members who are held accountable for their activities and deliverables are naturally motivated to behave in ways that produce higher-quality solutions. MSF promotes the ability to capture lessons learned, which by its very nature provides a validation of activities and deliverables that helps drive an increase in quality awareness. Each team member is accountable to the team and to respective stakeholders for achieving quality goals. In this sense, each team member is accountable for a share of the quality of the eventual solution. At the same time, overall responsibility is shared across the team of peers because any team member has the potential to cause project failure. The MSF Team Model holds everyone on the team responsible for quality while committing one group to managing the processes of testing. A test group drives a team to make the necessary investments throughout a project's duration. This ensures that quality levels meet all stakeholders' expectations. In the MSF Governance Model, as project deliverables are progressively produced and reviewed, testing verifies and validates qualitystarting at the beginning of a project life cycle and continuing through each track of activity. This model defines key checkpoints while suggesting interim checkpoints that, led by a test team, measure a solution against quality criteria established by stakeholders and the team. Conducting reviews at these checkpoints ensures a continuing focus on quality and provides opportunities to make midcourse corrections as necessary. An essential ingredient for instilling quality into solutions and services is development of a learning environment. MSF emphasizes the importance of learning through the Readiness Management Discipline, which identifies the skills needed for a project and supports their acquisition by team members. Obtaining appropriate skills for a team represents an investment; time taken out of otherwise productive work hours plus funds for classroom training, courseware, mentors, or even consulting can add up to a significant monetary commitment. The Readiness Management Discipline promotes up-front investment in staffing teams with the right skills, based on the belief that an investment in skills translates into an investment in quality. Learn from All Experiences
If all levels of an organization do not learn from what previously worked and did not work, how will anyone improve next time? It must be understood and appreciated that learning happens at all levels: at a project level (e.g., refining a project-wide process), at an individual level (e.g., how to better interact with other team members), and at an organizational level (e.g., adjusting which quality metrics are collected for each project). Capturing and sharing both technical and nontechnical experiences are fundamental to ongoing improvement and continuing success. Here are a few reasons why:
When you look at the marginal increases in the success rate of technology projects while acknowledging that the major causes of failure have not changed much over time (see Table 3-2), it would appear that as an industry those in business have not learned from their failed projects. Taking time to learn while on tight deadlines with limited resources is difficult to do, and tougher to justify both to teams and stakeholders. However, failure to learn from experience is a guarantee that failures will be repeated and a team once again will suffer through associated project consequences.
Learning from All Experiences in MSFMSF assumes that focusing on continuous improvement through learning leads to greater success (referred to as kaizen, the Japanese word meaning "philosophy of ongoing improvement").[9] MSF builds in natural checkpoints and reviews that help a team reflect and assess successful and not-so-successful aspects of a project. Knowledge derived from one project that then becomes available for others to draw upon decreases uncertainty surrounding decision making based on inadequate information. Planned checkpoints throughout the MSF Governance Model help teams to make midcourse corrections and avoid repeating mistakes. Additionally, capturing and sharing this learning create best practices from processes that went well.
MSF emphasizes the importance of organizational- or enterprise-level learning from project outcomes by recommending externally facilitated project checkpoints and post-project reviews. This information records not only the success of a project, but also characteristics of the team and the process that contributed to its success. Sharing lessons learned from multiple projects facilitates an environment of open communications, and as such interactions between team members take on a forward, problem-solving outlook rather than one that is intrinsically backward and blaming. Partner with CustomersHow often is a project successful by simply throwing the result over the "proverbial" wall and hoping that a team met customer expectations? Success is a joint effort. That is not to say that customers do a team's work. However, it is to say that customers should work closely and incrementally with a delivery team to ensure a solution meets their expectations. Partnering with customers is mutually beneficial because it helps drive down uncertainty, shortens the time to resolve requirement questions, and increases a team's understanding of the solution value propositions through regular contact. Partnering with Customers in MSFThe MSF Team Model represents an advocacy model that attempts to involve all stakeholders, including customers and users. The model differentiates between customers and users, and dedicates a separate set of advocates on a team for both. As discussed in much more detail later, customers are the people sponsoring and/or paying for a project. Users are the people who intend to use a solution. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 137