When assessing trouble projects, the first area I evaluate are requirements. A major red flag is the underutilization of analysts. There is a growing trend within in IT organizations to limit the role of the analysts to meeting scribes, technical writers, and trainers. This approach misses out on the true value a great analyst brings. If integrated fully into the project team; a strong analyst can significantly add project team’s ability to quickly delivery value to the customer by increasing the overall efficiency of the team.

Why don’t more teams fully integrate and use analysts? Simple, they don’t know how. Many IT organizations and project teams struggle with how to leverage analysts. This is even more evident in organizations that are strongly rooted in Agile principles. The traditional role of analysts no longer fit cleanly into many of the manifestos, frameworks or methodologies teams are using. As such, without a clear understanding of what analysts are suppose to do, many teams have just opted to remove them all together.

Without individuals within the team that are responsible for discovery, elaboration and alignment activities, most project team quickly find themselves chasing their tails. Proper incorporation of analysts into the project team activities is still very much needed. Below are seven guidelines to consider that may help to maximize the value of the analyst role within your teams.

Guideline #1: Respect the value of the analyst role

With the tightening of funding, organizations are insisting on seeing the return on investments from technology solutions efforts. Analysts are in unique positions to demonstrate this value. Thus, ensuring your project has a clearly defined analyst role is critical. Analysts sit firming between the business and the technology side. In Agile context, team typically deal with the Product Owner to derive the solution vision and define the minimum features. However, often times, the Product Owners is relying on someone to play to the role of analyst for them. These individuals focus on determining the business problem, defining the desired outcomes, and assisting the business with articulating those outcomes into specific functionality requirements leveraged by the technical team.

Even within agile and pseudo-agile software development teams, the role of the analyst is warranted and valuable. Without a strong analyst role, the project team runs the risk of not fully understanding the Product Owner/customer’s problem set. This lack of understanding often leads to ever shifting requirements, large amounts of rework, scope creep, schedule overruns, project team frustrations, and customer dissatisfaction.

Guideline #2: Use the Analyst to analyze and document

Projects are becoming increasingly complex. Many projects start execution without sufficient scope definition. In addition, it is typical for a project to already have a set deadline, budget ceiling and be understaffed. With these constraints, it is critical that someone on the project team be responsible for figuring out what the customer needs are (i.e., requirements, user stories, acceptance criteria, etc., ). Figuring out requirements can take a considerable amount of time which may include reading documentation, researching operational processes, clarifying information with numerous stakeholders and creating documentation. This is where a strong analyst shines.

Guideline #3: Allow the Analyst to relieve pressure on customer

One of the primary complaints from stakeholders is the amount of time projects take away from them performing their “real” jobs. If properly leveraged, the analyst can serve as pseudo-user or proxy Product Owner. Use the analyst to develop in-depth knowledge of the various user job functions, operational processes, policies, procedures and business environment constraints. By stepping into this slot, the analyst can successfully represent the business group and increase time flexibility for the stakeholders. In addition, the analyst is able to provide greater clarification to the technical team about the perceived stakeholder value of developed functionality.

Guideline #4: Allow the Analyst to relieve pressure on project technical roles (developers, architects and infrastructure engineers)

Although, I know a number of developers, engineers and architects that like to work closely with customers around requirements, it is not always the best approach. When dealing with small, maintenance or product feature enhancement type projects where there may not be strict timelines or scope, the Agile developer-customer relationship often works fine. However, for large enterprise or transformational projects, this approach can quickly run off track. No matter how well the intentions, eventually, there is a conflict on the amount of time that should be spent dealing with requirements verses actually developing the system. By identifying an individual on the team who is primarily responsible for requirements management, technical roles on the project can remain focused on what they do best. In order for technical project resources to feel greater comfort with allowing the analysts to take the forefront with the customer, the analyst must understand how to communicate information with the technical side of the house as well.

Guideline #5: Use the Analyst to validate that the project’s vision and outcomes align

When serving in the role of a Project Manager, one of the main things I tend to leverage my analyst for is breaking down the business needs into technical scope functions/features/components. Analysts can provide great insight into what is being asked and why it is needed. Understanding these two things clearly leads to reducing ‘gold plating’ and increasing the likelihood of successful project delivery.

Guideline #6: Leverage the Analyst to support change management

Analysts can be instrumental in controlling change. Analyst tend to become subject matter experts with specific products, processes and systems. This expertise can then be leveraged to identify, quantify, qualify, and prioritize changes. Controlling changes within a project enables the team to focus on the things that create value and will deliver the intended solution. In addition, leveraging analysts to spearhead change control boards after the bulk of the initial requirements gathering is complete is a great value add.

Guideline #7: Use the Analyst to bridge the transition gap between system deployment and operation

A common business complaint at the end of many projects is the lack of coordination between applications development and business operations. Often time, after the new or enhanced system/feature is deployed into production, the project comes to an abrupt end (at least from the user’s perspective). Even in organizations that have established “transition support periods”, this support typically focuses on addressing defects or basic user onboarding. This perceived drop off can leave business users struggling to absorb the new functionality. By leveraging the analyst to serve as the bridge, deployment to implementation transition can become closer to seamless for the users. The analyst can serve as a common face for users and often, if knowledgeable enough, can proactively identify and handle post-implementation transition issues.

Carla Griffin, BSC, MPM, PMP, ITIL, COBIT, has over 20 years of Transformational Program and Project Management experience in various industries (Government/Public Health, Financial Services, Information Technology, Claims Processing, and “Big 10” Consulting).