Mindsets


Foundational principles guide how a team should be oriented to maximize success, but what about orienting team members as individuals to maximize success? This orientation is called a mindset. A mindset orients each team member as to how he or she should approach solution delivery. Ideally, team members internalize these mindsets to drive their personal behavior. The following are a few mindsets that each team member should internalize:

  • Foster a team of peers

  • Focus on business value

  • Keep a solution perspective

  • Take pride in workmanship

  • Learn continuously

  • Internalize qualities of service

  • Practice good citizenship

  • Deliver on your commitments

Foster a Team of Peers

If your organization is able to embody the MSF foundational principles, especially empowerment and accountability, does it really make sense to run a project with a hierarchical project structure? If everyone understands the mission and its goals (i.e., shared vision) and understands his or her role and responsibilities in delivering a solution, doesn't it make more sense to treat everyone as a peer? This is not proposing anarchy or managing by committee, but rather that everyone shares responsibility for the successful delivery of a solution. Every role is singularly accountable for its respective aspect(s) of a project while being jointly responsible for a project as a whole. As you will see, there is still a Program Manager role, but that role is focused on delivering a project within project constraints, not on managing team members.

The mindset of a team of peers conveys to a team that each role has a "spotlight" on it at various times throughout a life cycle, that each role is an integral part of a team reaching its quality goals and delivering a solution that best meets all stakeholder needs. When everyone is empowered as equals, MSF avoids disadvantages imposed by a top-down, hierarchical structure of traditional project teams.

In MSF, everyone shares responsibility for the successes or failures of a project; MSF discourages singling out individuals for praise or blame because that undermines the foundation of empowering a team. The lowest level of recognition should be at a team level. Yes, it is nice to recognize star performers, but it should be done in the context of recognizing a team. Although unspoken, a project team usually knows who contributes most. Individual recognition is often better served in private venues such as yearly increases and/or bonuses.

Although each role has equal value on a team, the team of peers exists between roles and should not be confused with consensus-driven decision making. Each subteam (e.g., the test team) requires a form of internal organizational hierarchy for distributing work and managing resources. Team leads for each group are responsible for managing, guiding, and coordinating the team, enabling team members to focus on meeting individual goals.

Essential ingredients in fostering a team of peers are trust and respect. Trust and respect bind a team of peers. For example, team members need to trust that their fellow team members perform to expected levels. An organization must trust a project team to deliver a solution regardless of their selected approach so long as it is within project constraints. Team leads need to trust their team members.

Usually, there are 101 ways to complete every assigned task. As long as team members adhere to project norms and deliver as expected, they should have creative license to perform and accomplish the task. This ties directly into the principle of empowering team members. Without trust and respect, a team of peers starts to falter, which leads to micromanagement and seriously degraded ability to be agile.

Focus on Business Value

It is really quite simple: success is measured in terms of delivering business value. This means not only delivering something that customers need, but also includes delivering something customers want, which has value to them. To deliver value, everyone on a team needs to understand what customers deem valuable. Failing to provide customers with business value puts a project at risk: at risk of getting off course; at risk of spending lots of misdirected time, effort, and money; and even at risk of being cancelled.

Team members usually understand that they need to focus on business value. It is just that they often get distracted. Too many times solutions are delivered with cool features that provide different or little business value. Too many times a team polishes a solution where each successive layer of polish further diminishes business value. Too many times a team mistakenly focuses on those parts of a solution that are business value gap fillers (i.e., those parts of a solution that integrate high business value pieces). Too many times requirements are not stack-ranked based on business value. In short, business leaders fund solution delivery efforts to provide them with increased value or some business advantage. To be successful, as part of a shared vision, a team must understand linkages between their efforts and the business drivers, and must continue to deliver increasing business value.

For a team to better understand how to deliver business value, they need to keep customers in mind for all of those little decisions that every team member makes every day. This means that when team members try to make those decisions, they ask themselves: What way would best serve the customer? Where are their pain points? Keeping customers in mind at a grassroots level naturally percolates up to when those bigger decisions must be made. Most of the time this type of thinking is commonly called customer empathy.

Keep a Solution Perspective

Because of the size and complexity of most projects, when a solution is decomposed into actionable pieces, team members sometimes become myopic in their understanding of the ultimate solution. That is why so much emphasis is placed on the principle of having a shared vision. As team members deliver their portions, they need to be mindful of the overall mission, goals, and vision for a solution. Many times a subteam veers away from the vision while optimizing their area and believing they are acting for the common goodonly to find that they need to rework major aspects to bring it back in line with a solution; they get caught up in details and lose sight of a solution.

Having a solution perspective is not about how a role contributes to delivering a solution, but is about how a role delivers a solution that fits into a broader solution. In turn, that solution fits into an even broader solution, and so forth. A solutions mindset attempts to foster the ability of team members to holistically consider their respective efforts to develop a stand-alone solution and how they are accountable for its successful integration into a broader solution. A solutions mindset enables team members to carve out a portion of a broader solution and call it their own. This typically drives up a sense of ownership and pride of craftsmanship.

Adopting a solution perspective is also a team normalizer that supports being a team of peers. This approach means that everyone's job is to define, design, build, test, and deploy their solution as opposed to team members aligning themselves with their craft (e.g., I am a developer and therefore my job is to write code).

Having a solution perspective also encourages team members to focus on what is needed to deliver solutions and not to be caught up in lower-level details of how to deliver a solution. They should consider themselves as empowered business owners whose business is dependent on delivering their solution. This level of thinking should help team members resolve many day-to-day issues and decisions.

One way Microsoft fosters a solution perspective is by encouraging team members to adopt their solution and give it a life and personality of its own. Teams do this by creating a unifying solution identity, be it a logo, a cool-sounding code name, a mascot, or some other means where team members identify themselves as a part of a great whole versus a collection of loosely associated individuals (e.g., project rolling thunder with logo of a lightning bolt coming from an ominous storm cloud). This approach clearly identifies a project, clearly identifies a team, raises a sense of accountability, and serves as a mechanism for increasing team morale. Printing the team project code name on T-shirts, coffee mugs, and other group gift items is another way to create and reinforce team identity and spirit. This is particularly useful on projects that include virtual teams that are composed of elements from several different groups within an organization.

Take Pride in Workmanship

Unlike the principle of investing in quality, which conveys that a team and organization should take purposeful steps to facilitate quality, this mindset espouses that quality is not something to be delegated. Instead, quality is everyone's responsibility throughout the solution delivery life cycle. This mindset not only includes enabling increased quality within a team member's own deliverables but also includes driving up the quality of process enactment and project governance. Being ever vigilant, any team member can facilitate continuous improvement.

In a successful team, every member feels responsible for the overall solution quality; and every team member takes pride in what he or she produces. However, a team needs to invest wiselytoo much can cost a team. At the beginning of a project, a team must determine which level of quality is needed for the various aspects of the project.

Pride in workmanship involves passion and commitment. Taking pride in their work leads team members to perform their work at the highest quality possible, given their constraints, so that if they have to deliver tomorrow, they are able to deliver something of value. It is the idea of having a nearly shippable solution every day. It means that a solution meets or exceeds the quality standard(s) set by a project sponsor and accepted by the team at the beginning of a project.

An analogy that describes this concept is the automobile assembly line. Traditionally, workers put cars together from individual parts and were only responsible for the quality of their own task. When a car rolled off the line, an inspector checked it to see whether its quality was high enough to sell. But the end of a process is an expensive time at which to find problems because corrections are very costly to make at that point. Also, because quality was not very predictable, the amount of time required at the end of the line to determine whether the product was sellable was not predictable either.

More recently in car manufacturing, quality has become "job one." As work is being done (such as when a door is attached or a radio is installed), an inspector checks the work in progress to make sure that it meets the quality standards defined for that particular task. As long as this level of quality continues throughout the assembly process, much less time and fewer resources are required at the end to ensure that a car is of acceptable quality. This makes the process much more predictable because an inspector needs to check only the integration of the parts and not the individual work.

Learn Continuously

Given that most every project, team, and environment have uniqueness, each project presents opportunities to learn, experiment, and refine skills, processes, and procedures. To take advantage of these opportunities, continuous learning and adapting must exist at all levels of an organizationnot just be limited to team members.

Unlike a classic masterapprentice relationship, learning while on a dynamic team can come from any area and from anyone. Because innovation can occur with any team member, teams should be open and allow themselves to learn from each other. Encouraging team members to be innovative and to take acceptable risks likely results in success. When a team is given a chance to repeat those successes, it drives process improvement. Having a team learn from less-than-successful efforts is also valuable. Most people say that you learn much more from unsuccessful activities than you do when things go smoothly.

Continuous learning takes commitment from all levels of an organization. Time taken to extract lessons learned might divert time from other parts of a project, but this is a commitment to ongoing self-improvement through the gathering and sharing of knowledge.

Internalize Qualities of Service

As discussed in more detail in Chapter 8, "MSF Plan Track: Planning a Solution," qualities of service (QoS) define expected operational characteristics of a solution, such as the level of expected solution availability. It is essential for stakeholders and team members, not just architects, to understand QoS and how satisfying them affects deliverables. Otherwise, stakeholders and team members likely will make implicit assumptions about how a solution will behave. Because these assumptions rarely align, each team member needs to make explicit design decisions from the beginning to ensure QoS are satisfied. That way, implicit assumptions are converted into explicit QoS requirements. And QoS are explicitly designed into a solution from the beginning and are not treated as an afterthought.

Lesson Learned

It is very challenging to define QoS unless the customer(s) and the team can articulate the key attributes of a solution. In addition, it really helps if both parties understand the benefits as well as cost and schedule implications of setting QoS levels.

Being explicit about QoS assumptions is very important, especially when the solution being delivered replaces an existing solution. Stakeholders trust that a new solution will provide new and improved features and capabilities, and they are intolerant if a new solution does not at least match existing QoS of the legacy solution.


Practice Good Citizenship

Good citizenship means being trustworthy, honorable, responsible, and respectful in all aspects of how you interact with your fellow team members, with an organization, and with stakeholders and how you participate in a project and help deliver a solution. This includes being an entrusted steward of corporate, project, and computing resources. This includes openly and willingly sharing resources, information, and knowledge. Citizens act on and are mindful of the greater good.

Being a good citizen also means proactive reuse of resources and generating resources that can be reused. In the not-so-distant past, many teams built everything from scratch because it was not practical to reuse or extend existing components, scripts, and collateral. Even if it was practical, many teams resisted (often called the not invented here syndrome). With the advent of service-oriented architectures (SOAs), the mindset of reuse is more practical. Team members should first think to reuse and extend current assets and standards, not to reinvent unnecessarily.

Deliver on Your Commitments

Despite many embedded checks and balances, MSF runs on trust and empowerment. Trust and empowerment are earned, in part, by team members delivering on their commitments. MSF establishes an environment in which team members and stakeholders are able to trust that their fellow team members will deliver on their commitments. Because a project is a collection of interdependent activities, when one team member does not meet his or her commitments, it imbalances and jeopardizes the whole ecosystem.

To help meet commitments, each team member continually needs to make measured progress and not get bogged down by little obstacles and issues. It often helps if team members assume a frame of mind where missing a commitment (e.g., a deliverable date) is not an option. This should help drive creative decision making and serve as motivation to drive forward.




MicrosoftR Solutions Framework Essentials. Building Successful Technology Solutions
Microsoft Solutions Framework Essentials: Building Successful Technology Solutions
ISBN: 0735623538
EAN: 2147483647
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net