Welcome to the second post in The Compass Guide to a Successful Project series. Our initial post introduced Compass365 and gave an overview of our four key elements of effective project planning. That post went into detail on the first element: Initiation and Assessment.
The Second Key Element: Design
The word design means many things. Officially, it is the creation of a plan or convention for the construction of an object or a system (as in architectural blueprints, engineering drawings, business processes, circuit diagrams, and sewing patterns). At Compass365 it is how we solution to address needs and creatively think through a process of “how will this work” with our clients. The design gives us a blueprint or map to follow that we create collectively.
The design phase gives our clients an idea of how the system will look and work, via wireframes, mockups, drawings, diagrams, and partially configured software. In the design meetings, we show stakeholders options and outline the decisions they need to make about how the solution will ultimately function and how it will look.
Project Design Approach
Throughout all phases, we act as a guide, calling back to the client’s objectives and pointing out the pros and cons of incorporating new requests and features, as they relate to their original business requirements. We sometimes need to remind businesses of their own priorities – excitement, scope, and innovation all happen here in the design phase. We are the gatekeeper to keep businesses on track, which often includes reminding them why they started the project in the first place.
How do we do this?
We exercise their imagination. The design process includes all the primary players and establishes the storytelling thread, using the client’s story to show what they do best. This is where we learn about them as individuals. We find out who they are as well as what they need.
Who are the players?
Usually a mix of business owners, directors, day-to-day users of the solution, and IT management.
In the design phase, we use these discussions to map requirements into the technology. We iterate through a series of process design review meetings, capturing design specifications in Word or PowerPoint, documenting all decisions, out-of-the-box configurations, custom components, and assets that the company needs to prepare for. Both graphics and content are key, for instance, in a SharePoint intranet project.
We do not tell our clients what their design should be. We work collaboratively to help them choose the design that will best serve them. Ultimately clients agree upon the design because they will use it every day. We also talk about whether to use third-party products. As their guide, we demonstrate these products’ functionality, look, and usability to determine if they are truly valuable to the solution. We bring ideas from our years of experience and depth of knowledge of the Microsoft 365 ecosystem and other technologies that enable collaboration and innovation.
Many of our clients like to hear what other companies are doing. We use our expertise to give examples and guidance based on what has or hasn’t worked for others and trends in the industry, helping us understand what decisions they need to make.
Throughout the process, we always want our clients to know the value of what they are implementing. If the out-of-the-box features don’t meet requirements and we need to look at customization, we demonstrate how much value a feature or functionality offers. We need to save users time and money every day, but it’s not just a numbers game; extra cost sometimes brings high value. “Nice to haves” should be looked at as value vs money, including costs from customization and implementation. Value is always our guiding principle.
A few examples of projects and project areas and how we approach the design phase:
Our stakeholders include HR, Comms, Marketing, and other business divisions, as well as IT, engaged in designing the intranet. The modern SharePoint experience and available templates serve as the foundation for an engaging and useful intranet. We’ll share examples, build prototypes, work to enhance branding, and create web parts as needed to meet a high-value business requirement. Brand look and feel depends on the scope of the project and is a big part of the value discussion for intranet and portal projects. We approach from two different directions: implementing elements of the client’s brand, logo, and color palette with out-of-the-box features, or going the custom route. We talk about cost and control over every pixel of the design because cost and time to roll out are important. In many cases, customers choose the out-of-the-box approach, taking the SharePoint native route. When customers want tight control over branding, we will work with our partner, Akumina with an alternative interface that offers extensive control and customization of the intranet look and feel.
The Solutions Architects from our Business Applications team invest time to really understand a client’s business process – sometimes asking questions that the stakeholders hadn’t thought of. The volume and complexity of data helps us determine the data source, for instance, while the business rules, types of users, primary device, etc., will inform the design. We map those requirements into the platform, create prototypes and hold regular playback meetings to help our clients see the tangible result of their proposed design. Often, business users are new to Power Platform, and we spend time educating them and incorporating their feedback along the way to make sure the solution will meet the requirements and be well-adopted.
While not immediately apparent, there is significant design work involved in a SharePoint Online migration. After assessing the current SharePoint on-prem site and content, or the structure of file server content, we begin to plan the new home for their content in SharePoint Online. Following Microsoft best practices and with our client’s organizational structure, methods of working, and desired goals, we design the site structure and organization, ensuring that all relevant content has a home. We use prototypes here as well to guide stakeholder discussions and decision-making. We confirm the design and all decisions in a formal document and then configure the site and migrate the content. Key stakeholders participating in the design sessions are also being educated on how to use SharePoint Online.
Project Design Flexibility
We always advise leaving room in the budget for design flexibility. We begin the assessment and design with a “not to exceed” budget, leaving the next phase as a “rough order of magnitude” or “ROM” budget, to give wiggle room for changes and design decisions. You do not always know everything you need and how much it will cost to implement when envisioning the project. Once we get the initial design input, we re-estimate the phases and use the client’s design decisions to create that not to exceed number.
Business objectives come in many different forms. In making design decisions, we sometimes find we could automate something within the solution to better meet the organization’s needs, improve functionality, or save time and money. Budgets should take into account functionality needs, go-live deadlines, mandatory features, and replacement processes. Supporting the client’s objectives is no cookie-cutter endeavor. We prioritize and address the client’s needs and must-haves, and also look at the “what ifs” and put pins in them to revisit as needed.
Project Design Best Practices
Working with Compass365 is a conversation and a collaboration. Having a good mix of engaged stakeholders, decision-making capability, and a vision of what the client wants to accomplish is key. We want all key stakeholders to attend the meetings, capturing all decisions and iterations of the design in real-time. This is a collaboration; we do the heavy lifting, but we engage heavily with our clients. The more input we all put into the solution, the more likely employees will adopt it.
The same team we ask to test the product should be involved from the beginning, contributing to the design. Not only does this create a better product, but having stakeholders invest in the design phase prevents resistance later. Questions like, “what is this” and “why didn’t anyone ask me” are raised now, not as the system is rolling out.
Project Design Sign-Off
When the design phase ends, the design specifications must be fully signed off. We document all decisions that have been made and send the final version of the prototypes for review. We have one meeting to review, making sure all stakeholders have seen and approved all final versions, especially if the project is complicated or has multiple stakeholders. The final sign-off is usually done via email after our review meeting with our client.
The project design phase officially ends when the client accepts the design specification, and we get ready to implement the system.
Stay tuned for the next step in the Compass Guide to a Successful Project – Development