In my travels, I’ve noticed that too many companies don’t seem to understand certain fundamental methodologies and roles. I’ve written at length how enterprises fail to grasp what’s meant by Agile, and now I’d like to turn the lens to something even more basic, yet still misunderstood. This leads to something euphemistically termed role confusion.
There are a couple of flavours of role confusion: one where a company’s job titles don’t reflect those of the broader industry; another where the typical boundaries of a title or role are nebulous; and another where several titles perform similar functions. Title inflation is a cousin, and perhaps that would make another segment. For now, let’s look at how each of these can be problematic.
In the first case of not conforming to industry standards, the problem will likely be acquiring and retaining talent. If job titles and definitions don’t match, some qualified candidates might not even find your vacancy postings. If you call your sales reps dog catchers, you shouldn’t be surprised you aren’t attracting sales reps. I’ll return to this later.
In the second case, the title is close, but the functions don’t quite map. If this is only slightly off, you’ll be forgiven. Perhaps an employee’s prior employer was the one who got it wrong. Who’s to say? But if you are way off the map into territory clearly charted, you risk frustrating someone who excels at baking, yet is expected to bus tables. Sure, we all need to pitch in and perform tasks outside our roles, but this should be the exception rather than the rule.
The last case, will be perfect to dive into the main topic and explain by example. Most companies of any scale have project managers—if not by title, then by function. In the worse cases, people just manage their own projects to varying degrees of success, mostly challenged and unsuccessful. Many companies have business analysts, though definitions and focus differ significantly. A few companies have business architects, primarily because this is a function of scale.
Let’s look at each of these in turn from right to left, bottom to top.
Project Managers come in all stripes. In the software delivery world, they aren’t so much about operations, but outside of the software realm, they can be very operational, but their bread and butter is about delivery and execution. This is their wheelhouse. Project Managers inherit projects, and they take the proverbial bull by the horn with the goal of taming it and getting it past the finish line on time, under budget, with the anticipated scope and quality. Project Management is a function: input scope, specifications, budget, and time expectations, and the output will be determined. Along the way, they will identify and manage risk. They are also responsible for managing communication and documentation. Finally, motivating the team is a key part of the job. Project managers not aligned to either the business or technology are in a better position to deliver results without conflicts of interest related to reporting lines. An autonomous PMO of similar structure is a good remediator.
Business Analysts come in different flavours as well. There are the accounting variety, which are not on the menu for this discussion. There are functional and technical flavours, sometimes referred to as business systems analysts. As with Project Managers, I am more interested in business analysts who focus on business solutions solved by process and technology applications. Business Analysts help guide businesses in improving processes, products, services and software. They take data and stakeholder input to produce outputs. An effective Business Analyst understands the business with a given functional domain. Through dialogue and elicitation, they extract and manifest value propositions, which they distil down to feature functionality and requirements. Downstream, they feed the project manger and collaborate with the development team to ensure requirements are understood and executed properly.
Although Business Analysts and Project Managers appear to be on different level, they are most typically at the same level in an organisation. The tiering is a function of the image layout and the shared Delivery & Execution space.
Business Architects are another story. They not only operate at a higher level within the organisation, they reside to the left of Business Analysts and Project Managers. Even if a company is mature enough to warrant dedicated enterprise strategists, Business Architects typically plug into this strategic space. Where the company has no dedicated strategists, Business Architects should be expected to fill this void.
Where the wheelhouse of Business Analysis and Project Management is Delivery & Execution, Operational Planning is the hunting grounds for Business Architects. Business Architects have no role in Delivery & Execution. This role is about establishing frameworks and articulating concepts. Where Business Analysts operate within functional domains, Business Architects operate enterprise-wide. In very large organisations, junior Business Architects may tend to a portion of the enterprise, they still report up to a Chief Business Architect, who surveys the fuller picture.
Business Architecture is about the business. It is decidedly not an IT function. Although I’ve seen it instantiated this way, Functional Business Analysis is not an IT function either. Bad idea. Business Architects should be creating frameworks and archetypes that should provide a foundation for the business. Long-range roadmaps should outline the path ahead. The frameworks should be reusable and developed iteratively. And although the frameworks are created, they are not meant to be prescriptive. Centres of Excellence and Communities of Practice serve these functions. Business Architects work with these functions as well as with Business Relationship Managers to operationalise activity built on these foundations.
Coming back around from the top, although there is variation in how these roles are defined and reporting lines, just as it’s not a good idea to drink and drive, it’s not a good idea to blend these roles. Do so at your out peril—or at least efficiency. Each of these roles has its own headspace and proficiencies. A person who excels at one is unlikely to excel at another. Moreover, task switching is always a productivity and efficiency hit—no matter how much someone insists they are a multitasker. These positions fall along the spectrum from extremely tactical to strategic and in-between.
There is a path in the shared Delivery & Execution experience for Project Managers to become Business Analysts and vice versa, and there is a path in the sliver of shared Operational Planning for Business Analysts and Architects to travel. In fact, the majority of Business Architects were once Business Analysts and took that path. Another path is from Solution Architect to Business Architect, but that’s a story for another segment. Let’s just say that I don’t think that’s a scalable sustainable path and leave it at that.
Although I mentioned in passing, Business Relationship Manager, BRM, and Solutions Architects, I didn’t want to take the time to expand this segment. Neither did I touch on Programme, or Portfolio, Management. Just let me say before this comes to an end, that Business Analysts and Architects are business functions, Programme and Project Management should be independent or neutral functions, and Business Relationship Managers and Solutions Architects should report into technology functions. These are not hard and fast rules, but they are generally the most efficient. The most common reason these functions are structured differently relate to maturity, competency, or politics, effectively all boiling down to maturity in the end. The end.