In the spirit of collaboration, we’re featuring our amazing team in our new guest blog series. This is your chance to learn a little something about the men and women behind the screen and discover what drives them. Our team will share their expertise and introduce you to their role in the PixelMill process, including things that excite them in the world of SharePoint & Office 365.
Our first entry comes from our Marketing Manager turned Business Analyst (BA), Chloe Fox! She gives an in-depth overview of the business analysis process at PixelMill, an important phase (“Discover + Define”) that’s often overlooked or not given adequate budget. Chloe will explain why you do not want to miss this vital step if you desire the most qualified solution that’s designed and developed to meet your company’s unique needs. Come along with Chloe on this journey and find out why a BA just might be your company’s new BFF.
Discover + Define : How PixelMill Gets it Right with Research
Hi, I’m Chloe, PixelMill’s BA. The business analysis phase is essential to creating a strong foundation for your project. I’ll explain the key elements of the process that we use here at PixelMill and the benefits your team will receive from investing in this crucial phase. Without a BA phase your company could spend thousands of dollars creating a solution that won’t properly address your users’ needs.
Many companies that hire PixelMill have pre-existing sites, so for those we begin with a thorough Site Analysis. During this step, the BA works with the client to identify and define the strengths and opportunities in design and functionality of the current site. We also use this time to learn how current items are built and come up with a plan to improve back end systems to make them more efficient.
Why this step is important: We identify areas of site that should can be reused or repurposed (which saves you time and money) and uncover and define specific areas that need improvement.
The next step of the discovery phase is performing user interviews where we gather information from users at all levels (from stakeholders to admin assistants) including their day-to-day work issues, how they communicate internally and externally, and what weaknesses they see in the current systems that could be addressed with our solution. User interviews are done in person or over the phone and are usually held in a group setting with similar users.
Why this step is important: We pinpoint productivity issues and opportunities for improvement which will save your employees and your company valuable time in the long run. Also there is a direct correlation to your user adoption when users can participate in the process and know their input matters.
Business Requirements Document
When preparing the Business Requirement Document (BRD) the BA summarizes key takeaways from the user interviews and site analysis. The BA identifies the business functional areas that need to be addressed within the organization. Most projects will have anywhere from 4-15 business requirements. Broad solutions are suggested in the BRD, but these solutions are often high-level suggestions that can change by the time the project is in the design and functional requirements phase. Business requirements themselves should not change and should be used as Key Performance Indicator’s (KPI’s) for the project through all phases. The BA guides all project decisions ensuring they remain aligned with the defined business requirements.
Why this step is important: We define KPI’s which give us a clear way to measure the project. This ensures everyone remains focused on the important goals.
Functional Requirements Document
The Functional Requirements Document (FRD) is the base for the development phase. It describes all the functionality that’s outlined in the wireframes. The FRD is written for a moderately technical reader, giving valuable insight for both project champions as well as IT developers. The document does not dive deep into how scripts will be written, but it does clearly describe expected behavior and how PixelMill anticipates to build for that expected behavior. This document really serves as a roadmap for the project.
While the BA is writing the FRD, they’re also thinking about the SharePoint information architecture, noting custom content types, lists, and fields for the client to review and approve. During the FRD phase the BA will meet with the client many times ensuring that both the client and the PixelMill team clearly understand the expected functionality. During these meetings, the business requirements outlined in the BRD will be cross referenced to make sure our solution aligns.
Why this step is important: The FRD gives clear guidance to the PixelMill development team and also establishes a standard that you can hold the project to for expected functionality. This document really outlines the scope of the project for the Development phase. A clear scope guarantees that resources on the project are not wasted.
As you can see in this brief preview, PixelMill’s Discover + Define stage is just the tip of the iceberg in helping your team get the best portal possible. A PixelMill BA will advocate for you in all stages of the project while acting as a liaison to the design and development teams building your solution; this ensures that the portal addresses your company’s unique functional issues and requirements. In each step of this phase we’re digging into what your company needs in order to be more productive and effective. The most valuable aspect of the Discovery + Define phase is the knowledge and understanding our team and yours gain so the portal meets the end users’ expectations and your company’s business needs.