By Robert Bogue
Software development is done differently at every organization, and in every home office throughout the world. The process that one organization or person uses to develop software may work for their specific environment and situation but may fail miserably in another set of circumstances.
It is, in part, the differences in environments which make it so difficult to quantify the process of software development in a single set of terms that all practitioners can agree to. As newer approaches appear on the scene, such as extreme programming and agile development the perspective of the world on what the process should look like changes slightly or dramatically.
However, despite these changes there are some things that remain the same. There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. Although each of these processes may change to some extent based on the programming models and tools being used, fundamentally there are some roles, which every process has in one form or another. One person may be filling all the roles or a handful of the roles, or one very specific role. Despite this there is a need for all of the roles – each serves a purpose. The origanization chart below gives you an idea of how each position fits together within an organization.
There is a series of roles that exist in most software development processes. As mentioned above one team member may be filling many roles and some roles may be suppressed for a specific type of project but all of these roles exist in one form or another in every software development project:
- Subject Matter Experts (SMEs) – The subject matter expert is the person or persons from which requirements are captured. These are the people who know what the software needs to do and how the process works. The SME role is somewhat different from the other roles because it is constantly changing as new clients (internal or external) are brought in to help design a solution. SMEs are rarely from IT – except when the solution is being designed to support IT. SMEs are most frequently the person who will receive the benefit of the system.
- Functional Analysts (FAs) – Functional analysts have the unenviable roles of eliciting clear, concise, non-conflicting requirements from the Subject Matter Experts who may or may not understand how technology can be used to transform the business processes in a positive way.
- Solutions Architect (SA) – The technical architect is responsible for transforming the requirements created by the Functional Analysts into a set of architecture and design documents that can be used by the rest of the team to actually create the solution. The Solutions Architect is typically responsible for matching technologies to the problem being solved.
- Development Lead (DL) – The development lead’s role is focused around providing more detail to the Solution Architect’s architecture. This would include detailed program specifications creation. The Development Lead is also the first line of support for the developers who need help understanding a concept or working through a particularly thorny issue.
- Developer (Dev) – The heart and soul of the process, the developer actually writes the code that the Development Leads provided specifications for.
- Quality Assurance (QA) – The quality assurance role is an often thankless position that is designed to find bugs before they find their way to the end customers. Using a variety of techniques ranging from keying in data and playing with the system to formalized, automated testing scripts the Quality Assurance team is responsible for ensuring the quality of the solution and it’s fit to the requirements gathered by the Functional Analyst. Sometimes the QA team is known by their less flattering name of testers.
- Deployment (Deploy) – The deployment role is the one which packages up all of the compiled code and configuration files and deploys it through the appropriate environments or on the appropriate systems. The deployment role is focused on getting the solution used. To that end the role may include automated software installation procedures or may be as simple as copying the files to the appropriate place and running them.
- Training – The training role is responsible for documentation for the system as well as any instructor or computer based training solutions, which are designed to help the users better understand how the system works and what they can do with it.
- Project Manager (PM) – The project manager is responsible for ensuring consistent reporting, risk mitigation, timeline, and cost control. The project manager role is a problem solver role. They try to resolve problems why they are small so that they can be handled more quickly and with less cost.
- Development Manager (DM) – The development manager is responsible for managing multiple priorities of conflicting projects. The Development Manager role is also an escalation for issues from the team, which it is unable to resolve internally.
Of course, each organization has it’s own take on these roles; however, these are the roles you’ll see most often in an organization doing development.
Over the course of the next few weeks, articles will be published that delve deeper into each of the above roles.
Critical Skills for Every Role
In the articles describing each role there is a section, much like this one, which is designed to support a bulleted list of items that are critical to the success of the role. During the creation of the series a common set of skills was identified that were essential business skills that professionals in nearly every role needed to consider during their career. Rather than repeat them within the individual articles describing each role, they have been brought together here so that you could consider the impact of these roles in whole no matter where you are in the software development process. The common skills to all roles are:
- Understanding Business – Although some roles are focused very specifically around certain aspects of understanding and converting business requirements, every role in the process should have an awareness and sensitivity to the business processes and needs which require technology in the first place. Without this technology may be implemented but it may not solve the real needs and will therefore be considered a failure.
- Broad Understanding – Although an understanding of software development is critical there are other areas where an understanding can be invaluable. For instance, understanding how computers work internally including memory, cache, hard drives, etc., can help you learn how to more appropriately conserve those resources. Similarly understanding networking can help in the development of applications, which are compatible or even friendly to the networks that they’re working across. SMEs broad understanding of the industry can be invaluable in terms of creating solutions that fit both the organization and the industry. The QA team can benefit the project by a broad understanding by minimizing QA costs while improving testing coverage. In short, a broad understanding can help every role.
- Multiple Perspectives – The ability to approach solutions from multiple perspectives is critical to software development. Understanding how each person who is working on a problem views an issue – or how different customers will view the solution is important to be able to find the best solution based on all of the information. There are always multiple ways of viewing – and solving – a problem. The trick is to find the best one from the list of possible options. The larger the list of options (perspectives) the better the solution.
- People Skills – Also known as soft skills, the ability to interact with other people and to be a part of a team is essential to nearly every role in a software development project. The lower the overall people skills of the team the higher the likelihood that the project will end in some explosion.
- Lifelong Learning – Although some might argue that the perspective of being a life long learner is more of an attitude than a skill, it is a critical part of being in a high-change industry like IT in general and software development specifically. What is learned today will be obsolete tomorrow. The only way to stay ahead of the game is to approach life from the perspective of continuous learning. Each new experience is a new opportunity to learn and each new year brings with it the need for skills renewal.
In the next article, the first detailed review of a role in the series, we’ll delve into the role of the SME in the process and what specific skills can make an SME stand out from the rest.
Anatomy of a Software Development Role: Subject Matter Expert
In Cracking the Code: Breaking Down the Software Development Roles I gave you the 50,000 foot view of the human side of the software development industry and the various roles involved. Here and in the articles to follow I will provide you with details on each of the key roles.
The role of the subject matter expert (SME) isn’t so much a role that the core information technology person plays normally, however, the role is an important part of the development process. Sometimes subject matter experts are business owners or business users. In most cases they are most often called "Client" Or "user". Figure 1 give you an idea of where the subject matter expert fits into the bigger picture of an organization.
SMEs are the people in the process who provide the information on what needs to be built. They serve in the most important role in the development process – despite not being a part of the permanent development team.
Without the subject matter expert there would be no need and therefore no development.
What is a Subject Matter Expert?
Subject matter experts really fall into a few categories. The first category is the business owner who initiates the development process. For internal development this might be the manager who is sponsoring the project. For external development projects it might be the customer paying the bills. For software development companies the SMEs are most often the users of the software who understand what the product is supposed to do the most or at the very least what the product is expected to do.
SMEs provide all of the raw material for the development process this includes the requirements for the system and how it will be used. Their input describes the problem or the opportunity that the software solution will ultimately solve.
Who is a Subject Matter Expert?
SMEs are perhaps the most broadly described part of the development process. Because they can come from all walks of life, all levels of awareness of the software development process, and all levels of interest, trying to describe them is a futile process.
The most defining characteristic of a SME is the fact that, with few exceptions, they won’t understand the software development process. They are not a reoccurring part of the process and therefore they won’t have experience with what is happening-nor should they. This lack of understanding regarding the process is not a critical limitation, because the SMEs will work with a Functional Analyst who will guide them through the process. It is the FA’s job to understand the information that the SME has to share and to guide them through understanding how the process will work.
What Isn’t in Their toolbox?
Unlike most roles, which bring extra skills to the table, the SME removes some of the inherent skills that other members of the team possess.
As a part of a development team, here are some skills that you should be careful to avoid assuming a SME has:
- Don’t assume that the SME will clearly communicate what they know. Most people aren’t good at clearly organizing their thoughts on a topic and communicating them in detail. The expectation that the SME can turn on a faucet and start spewing out information in a way that the rest of the team can understand it is unrealistic. Set expectations should be that they wouldn’t be able to simply drop their knowledge directly into a document or even into a discussion. It should be expected that things will be left out, some processes may be misunderstood, and that an individual’s idea of current priorities might not match that of the company.
- Don’t assume that an SME will understand models Architects, Development Leads, Functional Analysts, and other members of the team often develop fancy diagrams to describe complex program structures. These structures are readable because the development team has learned how to read them over time. The SME may or may not be able to read technical diagram. Because they are largely outside the development process, they shouldn’t be expected to read such documents. Another way to think about this is to think about it is to think about reading a blueprint for a building. While the basic structure may be understandable from a blue print, not everyone will be able to fully understand the meaning of all the lines and numbers on the document.
- Don’t assume that a SME understand or can use defect logging and tracking systems. Some SMEs won’t have the skills to even track the discrepancies from what they want. They’ll need help getting their knowledge into the systems used to drive the software development process.
- Don’t assume that a single SME has all the answers. Each person has their own perspective SMEs are no exception. You may need to work with dozens of SMEs to reach a single consensus based on the amount of knowledge the SME has, the scope of the solution you’re trying to create and the lack of consensus in the industry or organization.
Where’s the Role Heading Anyway?
There will always be a need for subject matter experts – particularly those who can clearly articulate the needs the organization faces. Although SME is not the primary role that an Information Technology person typically fills it’s one that can be a great asset for an organization.
If a SME shows particularly good skills at articulating the business needs then perhaps there’s the opportunity to take a part-time or full-time role as a functional analyst (FA). The functional analyst’s job is to create clear, precise communication and to support the SME role. This combination makes it a natural path for those SMEs who become hooked on the software development process and want to be more involved.
Of course, the path is not paved in gold. The SME will need to focus on being able to document details, extract information from other SMEs, pay attention to the details, and in general become a more integrated member of the software development process. SMEs who want to make the leap to being a functional analyst will have to accept a greater level of process and technical knowledge while leveraging their familiarity with being an SME and the struggles that a SME has in working through the process.
What Makes a Subject Matter Expert Stand Out?
Being a subject matter expert isn’t a career in the same kind of way that being a developer is a career. In most of the roles in the development process the core learning is around the skills and technologies of developing software. The SME is instead developing a deep understanding of a process, an industry, and in some cases an organization. The SME’s value is their unique understanding of the problem that the development process is designed to solve or at least help resolve. In this way a SME is focused on being the thought leader and expert for a small set of information.
SMEs stand out from the crowd when they deliver industry presentations that call attention to their complete understanding of how the industry – or one part of the industry works. This process requires a willingness to get in front of large groups to speak and the drive to develop presentation skills that are very good.
In addition SMEs can cause themselves to stand out by writing articles for trade or industry journals. Writing an article is great in itself because it requires a certain level of clarity around the topic being written about. However, the real power is in being published in an industry magazine because there is an implied branding for the kind of quality of person who writes articles magazines. This can be immensely powerful in making you stand out from the crowd.
In a less public way the SME can stand out from the crowd by learning how to interact with different personalities to develop a network of relationships in the organization or industry that they are working in. It is rare for an SME to clearly understand the challenges faced by the producer for the organization, the sales department, the executive staff, and all of the other various departments. The more that an SME understands about the operation and hurdles facing the organization the more valuable they are in their organization and as an SME.
The Good, The Bad, and the Ugly
The Subject Matter Expert role in the software development lifecycle has its ups and downs just like every other role within the process. Here are a few examples of what’s good about the role and a few items to watch out for:
- Good: The role in the project is generally short lived. Projects tend to come and go
- Good: Subject matter experts are a generally well-respected and necessary part of the project.
- Good: Subject matter experts have a chance to interact with numerous people at all levels within an organization. This is often great exposure for being noticed within an organization.
- Bad: Since software development isn’t the primary process of an SME most feel a bit like a fish out of water.
- Bad: Although generally bright intelligent people the rest of the software development team may have trouble understanding the business that a SME is describing since they’ve not been a part of it. An SME may have to explain things from a couple of points of view for it to be fully understood.
- Ugly: Participating in a software development process may require more time than you’re used to.
- Ugly: SMEs may have to interact with geeks and bear through discussions on topics that won’t ever help them in their daily jobs.
The subject matter expert is the genesis of the software development process and can be an invaluable member of the team. Because their involvement in the software development process is short lived there is a role to guide them through the process. That role, the functional analyst, is also the next step up for a SME who’s looking to become more involved in the often chaotic process that is software development.
The role of Functional Analyst is one of the keys for successful software development. In Cracking the Code: Breaking Down the Software Development Roles you get a high level view of the software development industry and the various roles involved including that of the Functional Analyst.
The role of the functional analyst (FA) is to capture, consolidate, and communicate the information from the Subject Matter Expertss (SMEs) to the rest of the team. This may seem odd if there’s only one Subject Matter Expert; however, the typical case for a sizeable software development project is that it takes several SMEs in order to provide the necessary information to create a solution. Because of this the Functional Analyst is a critical link between the Subject Matter Experts providing the business requirements and the rest of the team trying to construct the solution.
Depending upon the organization that the software development is being performed in the functional analyst title may be called by other names as well. Another very common label for the FA is Business Analyst, or sometimes simply analyst. No matter what the name, the need to help capture, consolidate, and communicate the information from the SMEs to the rest of the team is the critical, bridge-the-gap, role that this person plays. An organizatonal chart gives you an idea of how each position fits together within an organization.
What’s a Functional Analyst?
The Functional Analyst is the facilitator for the Subject Matter Experts. The FA takes their input and transforms it into something that the development team can understand. One of the key components of this is clarifying the intent of the SME. The FA will spend a great deal of time asking questions like "What do you mean by that?" or "How does this fit in with what we were talking about earlier?" Questions like these expose potential, often subtle, differences in meaning between the SME and the rest of the development team. More importantly, these questions expose assumptions regarding business logic and processes that may not be clearly stated – or even stated at all by the SMEs.
FAs are also responsible for identifying and resolving conflicting requirements. If SME number 1 says the sky is blue and SME number 2 says the sky is red, it will be the FA’s responsibility to resolve that discontinuity. This may be done by getting the SMEs together to agree or merely in understanding the different perspectives. For instance, perhaps SME number 2 was referring to the sky on Mars. A less abstract example would be if SME 1 considered the way to uniquely identify a customer to be using a person’s social security number, where as SME 2 considers a customer to also include people from outside of the United States who don’t necessarily have a social security number. If uniquely identifying a client is important, then it is the FA’s responsibility to identify this and document the requirements.
Through the software development process a document or set of documents are being developed. These documents, the requirements documents, will represent the contract between the business that wants a solution and the software development team that wants to create the solution. A requirements document is, at the basest levels, a listing of all of the features or aspects that the final solution should have to fully solve the problem that the SME is describing.
The documents need to be understandable both by the SME and the development team. The SMEs will need the document to validate that the requirements for the project are correct in every detail. The development team needs the document so they know what is to be built. To accomplish both objectives the documents must be brief but thorough. They must also be expressed in both business and technical language. Done correctly they are the perfect balance between competing forces.
Getting Started as a Functional Analyst
In Real Estate it is said that there are only three things that matter: "Location, Location, Location." In that is a simple truth that sometimes there is one key attribute that drives all the rest. In the case of the FA that one attribute, or skill, is clear communications. So the starting point for a functional analyst is becoming a great communicator. Unlike Ronald Regan the objective in becoming a great communicator is not inspiring people with a vision. It is, instead, developing precise communication that will allow discovery of inner meaning and inconsistency that is essential.
Learning these skills is best done by working in positions requiring either leadership or detailed documentation. Leadership positions in professional or community organizations is an obvious target for training for the FA role, however, those roles require so many more things that they can often be distracting from the core skill that the FA needs to develop. A better role is the often-neglected role of secretary. While the obvious thought here is that the secretary is simply someone who is taking notes, the role can actually be an opportunity to safely develop the core skills for the FA role. Another benefit is that this role is rarely as contested as the role of leader of an organization.
Precision communication in most professional or community organizations isn’t a overt requirement. It is often lacking because of the volunteer nature of the organization; however, most organizations appreciate the addition of the skill. The ability to clearly articulate the situations faced by the organization through precision communication is an immensely powerful tool for helping the mission of the organization. This being said, community organizations are often a safe place for the FA to learn this skill. The secretary role puts the potential FA into the position of being enabled to ask the detailed questions. As the note taker it’s generally acceptable to others to ask the questions like "Can someone summarize what we decided?" or other questions that drive towards validating a common understanding. In addition questions such as "Can we clearly define what we mean here so that there are detailed notes of our commitment?" can be asked to drive into more precision communications. This is the exact kind of behavior that the FA will need to use to elicit clear communications from SMEs.
Building a requirements document is usually a key responsibility of the FA. Creating a good requirements document requires an insight into knowing when detail is necessary and when additional detail would only serve to clutter up the understanding. Just as there is no one recipe for creating cookies, there is no one formula for creating an awe-inspiring requirements document. In many ways creating a good requirements document is as much of an art form as it is about the science of capturing specific, numbered requirements.
What’s in their Toolbox?
The functional analyst’s toolbox is, first and foremost, a toolbox filled with communication and relationship skills. Although the FA has a set of technical skills, their greatest asset is their ability to communicate with others and to work relationships with others in the organization who can help to weave the SME feedback into context.
The FA’s technical tool box is not extremely specialized, they largely have to use the same tools as other members of the software development team, however, in their case they sometimes have to be more skilled at the basic word processing, spreadsheet, and general office tools’ use in order to support their deliverables.
One of the most important tool to know how to use is a word processing program. An FA may need to know how to use a word processing program at a more advanced level that others on the development team. The FA might need to create templates, develop large documents, and clearly convey requirements in a written format. The FA will need to understand the use of styles in the word processing program to support consistent formatting throughout the document. The role also needs to know how to create indexes and tables of contents so that the documents they produce can be useful reference documents as well as a readable introduction to the problem.
Another tool that the FA might need to understand and use is a spreadsheet tool. They must be comfortable collecting, organizing, and combining a variety of lists including mapping requirements to the design feature points created by the architect and the development leads. They must further then help to map requirements to the testing scripts created by the quality assurance role. An understanding of how to manipulate data in a spreadsheet facilitates all of these mappings.
The last tool I’ll mention that is in the toolbox is a drawing program, such as Microsoft Visio, which allows for the definition of use cases, process flows, and other diagrams that would be nearly impossible to express in words alone. The ability to use the program to accurately depict a wide variety of complex ideas is essential to crossing the chasm between the SME’s knowledge of the problem and the ability for the software development team to solve the problem. The generally accepted practice for diagramming is becoming UML (Unified Markup Language). UML allows you to describe relationships, states, and other common requirements that are best expressed in a graphical way in a standardized way.
Where’s the role heading anyway?
There was once a time when people predicted that everyone would be able to write their own software. They would sit down at a computer and just tell it what they wanted. The computer would write the program from this dialog and thus developers in their current incarnation would no longer be a necessity. This vision is all but gone from the heads of most practitioners. As more became known about what people wanted to do with computer and the rate of growth of their demand it became clear that there would always be increasingly more complex problems to solve.
A part of that realization is the realization that our ability to accurately describe the problem determines the ability for the problem to be solved. Most people are incapable of clearly and precisely articulating – to the level necessary — the problems that they’re trying to solve. This is a problem that is getting larger and not smaller.
This is the very problem that the functional analyst role has been created to solve. The functional analyst’s goal is to refine the understanding and communication from the subject matter experts and convert that into the clear, precise vision necessary to create a solution. Because of the growing need to automate in order to be competitive and because of the increasing difficulty for clearly articulating true business needs, the functional analyst’s role is more important now than it ever has been.
Standing Out in the Crowd
One way to stand out from the crowd as a FA is to become adept at dealing with differing opinions and conflict. The ability to gather a room full of disagreeable people and getting them to agree is a skill that is difficult to master but one which will show its value relatively clearly. Disagreements about what the problem really is – is common between SMEs. Sometimes SMEs are able to work the problems out amongst themselves. When they can’t, it is a powerful FA who can jump in and work through the problem.
Another way to stand out from the crowd is to develop requirements documents that are clear, precise, concise, and meaningful. The ability to develop requirements documents that are clearly understood by the entire software development team is rare even in a role where the primary purpose is to develop requirements documents.
A FA will also stand out when they show that they are keen to listening rather than more focused on presenting solutions. It is not the job of the FA to provide the solution, but rather to document and connect the requirements. SME will recognize a functional analyst that is more interested in hearing from them on what the requirements are, rather than one that presumes to know the answers already. By listening to the SMEs and by taking note of what is being said, an FA can build relationships that can help them in the future.
The Good, the Bad, and the Ugly
As with any role there will be good with the bad and then there will be the really ugly. The functional analyst has the opportunity to set the software development process on the right path by carefully controlling how the process gets off the ground. There are the key points for the role:
- Good: Key role in the definition of the solution. Being at the start of the process the FA has the greatest opportunity of any member of the software development team, to get the project started in a way that will create the best solution.
- Good: Interaction with everyone An FA has the greatest opportunity to interact with everyone on a project. This includes people on the development team as well as people outside the development team. Often this can include higher-level people within an organization. Such exposure to can be great for building a positive reputation and a strong career.
- Bad: Not all SMEs are created equal The quality of SMEs that a FA must work with will vary greatly. Some SMEs will make the FA role easy and others will make the FA want to commit acts of violence.
- Ugly: Conflict For most FAs conflict will be a normal consequence of daily work. This can get downright ugly at times – resembling a session of the Taiwanese congress.
- Ugly: All fingers often point to the FA. If the FA does their job, then everything should work out. If something is found to be missing from the solution, then the FA is often the role that is blamed first.
The Functional Analyst can be described as the "bridge across troubled waters." Their role is to bring together two very different perspectives. This process is done through conflict management, listening, and clearly communicating. The true armor that the FA has against the slings and arrows that will likely be thrown at them is the armor that they build in the development of a rock solid requirements document that accurately captures and communicates the vision of the SMEs and removes areas of potential misunderstanding by illuminating the dark crevices of detail that hide in everyone’s vision of a solution.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server – Networking . You can reach Robert at Robert.Bogue@CroweChizek.com