Microsoft Solutions Framework. Part 2. The Mindset of MSF. MSF Group Model

The basic principles described earlier determine how to orient the group to succeed. Orientation of individual members of the group for more effective work is called “way of thinking”. Each way of thinking helps team members achieve their goal in implementing the solution. Ideally, the members of the group feel so comfortable within these images of thinking that they use them not only at work, but also outside it. Here are a few images of thinking that each member of the group should follow.

The Mindset of MSF

  • Promote the formation of a group of equivalent colleagues. If your organization can apply the basic principles of MSF, in particular concerning incentive powers and responsibilities, does it make sense to work on a project with a hierarchical structure? If everyone understands the main and auxiliary goals, shares a common understanding, knows their roles and responsibilities, then everyone acts as equals and should treat them equally. This should not be regarded as a proposal to organize anarchy or committee. This means that all members of the group share responsibility for the successful implementation of the project. Each role is responsible for the relevant aspects of the project, and all roles bear collective responsibility for the project as a whole. Apparently, the role of the program manager is still there, but it is concentrated on the implementation of the project within the limits set by the limits, and not on the management of the group members.
  • Focus on values for business. Success is measured in terms of value for business. This means providing not only what customers need, but also what they want and appreciate. To do this, each member of the group must understand what exactly customers consider valuable. If the client does not receive business value, the project is exposed to risk, for example, the group may go astray, spend a lot of extra time, effort and money, or the project can be canceled altogether.
  • The solution must be promising. When analyzing solution components because of the size and complexity of most projects, team members sometimes look too closely at small details and forget about the solution as a whole. Therefore, so much attention is paid to the general idea. As team members provide their components, they need to look at the overall goal and presentation of the solution. Too often, a subgroup optimizes its field, believing that they are acting for the common good. But then they discover that they need to rework certain aspects so that their component is consistent with the solution. Members of the group become entangled in the details and forget about the whole solution.
  • Take pride in your craft. The group not only has to invest in quality, but participants also need to see that quality is as much their responsibility as other members of the group, so one should not delegate tasks to someone else. Quality is a shared responsibility within the entire life cycle of solution development. This way of thinking not only improves the quality of the member’s own results, but also improves the efficiency of processes and the management of the project. Thanks to him, each member of the group seeks to better understand what skills are needed to achieve a common goal. Tracking the quality of their own work and providing the best results, the members of the group will be able to constantly improve the final product.
  • Do not stop learning. Sometimes, to achieve the ultimate goal, it is not enough to be proud of your skills. Team members must learn new skills to become better. Given that most projects, groups and environments are unique, each project provides opportunities for learning, experimenting, and improving skills, processes and procedures. To take advantage of these opportunities, continuous learning and adaptation processes must exist at all levels of the organization, and not just for the members of the group.
  • Implement quality of service levels. Quality of Service (QoS) determines the operational characteristics of the solution, such as the expected level of availability. It is important that stakeholders and team members, not only architecture specialists, understand the principles of quality of service and know how their implementation affects the final result. Otherwise, stakeholders and group members are likely to make implicit assumptions about how the solution should work. Since such assumptions are rarely agreed upon, each member of the group needs to make explicit decisions from the very beginning of the project work to ensure the required levels of quality of service. Thus, implicit assumptions are transformed into explicit requirements for QoS, which are explicitly built into the solution from the very beginning of the work, rather than being built on later.
  • Encourage solidarity. From the point of view of software development, solidarity means trust, honesty, responsibility and respect for all aspects of the work. It, including, determines:
    • how to interact with team members, with the organization and stakeholders;
    • how to participate in the project and assist in project implementation, including efficient use of corporate, project and computing resources (which include common resources, information and knowledge). Joint members of the group act for the common good.
  • Fulfill your obligations. Despite many built-in checks, MSF relies on trust and full authority to achieve which, the members of the group, including, must fulfill their obligations. MSF forms an environment in which team members and stakeholders can trust the results of their colleagues. Since the project is a set of independent actions, if one member of the group does not fulfill its obligations, it jeopardizes the entire project.

MSF Group Model

The MSF group model shares typical operations for implementing solutions and responsibilities in seven groups. These groups are interdependent and multifaceted. As indicated in the table below, in order to use a balanced approach, these roles can provide a unique view of what is necessary for the project, what needs to be defended, and what goals should be associated with implementing the solution. These roles can be combined for small groups and expanded for larger groups.

These roles do not imply any organizational chart or set of positions, as they are very different in different organizations and groups. Most often, these roles are shared among different groups in the IT organization and, sometimes, in the business user community, as well as among external consultants and partners.

In the following we will consider the Management Model, the Checkpoints and the iterative approach of MSF.

Leave a Reply

Your email address will not be published. Required fields are marked *