Skip to main content

Tag: Team

Road to the Perfect Project – Part 2

Written by Cynthia Low on . Posted in Articles.

Project Leadership is Critical

The most important person on a project is the project manager. A good project manager with a supportive management style can make a project, and a bad one with an aggressive management style can single-handedly cause it to fail. I have seen both happen. As an ideal, the project manager will have personal technical experience that matches functionally the work being performed on the project. For instance, if it involves requirements elicitation, he/she should have personally done that kind of work. In a cradle to grave development effort, the more technical breadth that individual has the better. They absolutely must have excellent writing and presentation skills, and must be able to interface with both the customer and their own line management. The project manager has to have had management experience, some of which should be at the level required for the project.

After that, it is critical to select a high quality set of senior analysts for the project. This includes both business analysts and systems analysts. These people must have the requisite technical skills and experience to match the project’s needs. For example, a project might need senior analysts with skills in requirements management, database management, system architecture and design, and system testing. At a minimum, they must have successfully done the type of work to be performed. If specific tool sets are to be used, in the ideal they will have worked with those tools. As with the project manager, communication skills are a must. In addition, some supervisory experience is needed. Ideally there will be some experience overlap. For instance, a person with both requirements management and system testing skills is more valuable than someone who only has requirements experience because they can cover for a missing system tester.

I will call this set of people the Leadership Team.  The Leadership team must be individually flexible, and able to work together as a team. That is, they must be team players. Positive interpersonal dynamics among this set of key people must exist. Achieving consensus should be more important to them than individual heroics. If the team clicks, and they work together synergistically, the whole does indeed become more than the sum of its parts. In my experience, it is impossible to completely staff a project with super stars. They just are not going to be available when needed, and the cost is prohibitive. But given the existence of a synergistic leadership team, it is quite workable to use journeyman, and even some junior level staff for all remaining project functions, provided that the Leadership Team monitors and mentors them.

The reverse of the staffing coin is to ruthlessly cull out poor performers or discontents at any project level or role. These people can directly cause technical problems, and they will indirectly adversely affect project morale. If they are allowed to linger on the project they can and will make costly mistakes and they can and will negatively impact the performance of other project team members. It can be really painful to dump a malcontent, especially one who does not want to go. HR departments do not like wrongful termination suits no matter what the merits. Regardless, suck it up, and do what it takes to get rid of them.

Partner with Your Customer

To bring a system into existence, there is generally a project organization that is doing the work and a customer organization that has a need for a system and is financing the project.  In my personal experience the customer has been a government agency, which provides the experience base for this discussion. Unfortunately, as many have experienced for themselves, there is a tendency for the customer to try and dominate the customer-project relationship. All too often the customer tries to rule by intimidation and, all too often, they force non-optimal technical decisions. This creates a jointly adversarial relationship. And that causes poor project morale, lackadaisical effort, and high project turnover. Results are typically poor. In short, you can have a great project team and still fail due to the customer not holding up their end.

To improve the project’s chances of going smoothly, those two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative. When real partnering does occur, and both sides hold up their end of the bargain, results tend to be excellent. Technical people enjoy their project; they work harder, and they stay around. The customer tends to get a more user-friendly system, which they are happy with. It is a win-win situation.

Most of you will have only worked the project side of this relationship, and if you are lucky you may know what partnering looks like from the project side.  I have personally worked both sides of the fence. Here is what partnering looks like from the customer perspective.  It starts with the RFP. That document is well written, and expresses exactly what the customer expects the project to do and deliver. If a set of system requirements is provided with the RFP, it is professionally produced and clearly and fully expresses what the system is to do without forcing major design decisions. This will allow the project to correctly estimate project costs and make proper staffing decisions. On startup, the customer provides a briefing to the project staff, at which time any applicable existing documentation is turned over to the project. The project is invited to do its own briefing on how they plan to do the work. If on-site, adequate space, workstations, and connectivity are provided on day one. Even if off-site, some dedicated space, including a small conference room is provided. Technical questions and issues posed by the project are promptly and fully addressed. Access is provided to potential users, either for requirements elicitation (the ideal), or requirements validation and expansion.  Customer people attend all project briefings and project peer review sessions to which they are invited. Deliverables are promptly and thoroughly reviewed, and well-written formal comments are provided to the project. If needed, meetings are held to resolve conflicts. If the project is big enough, joint configuration control and risk review boards are formed.

On the project side, transparency is critical. Nothing is hidden from the customer. Any problems encountered are promptly conveyed to the customer for joint consideration. Schedules are rigorously met; documents produced are of high quality, including lack of grammatical or spelling errors; emerging user interfaces are offered for user review, and appropriate adjustments made; staff of the appropriate quality are placed on the project and vacancies are promptly filled.

Look for Part 3 of this series in the next Business Analyst Times online in mid-February.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management.  He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University.  John is the “Project Whisperer”.  His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

 © John L. Dean, 2008

Road to the Perfect Project

Written by Cynthia Low on . Posted in Articles.

Introduction

Ever since software development projects have been around, people have been coming up with ways to help ensure they come out well. Unfortunately, history shows us that there is no process, methodology, or toolset that can guarantee project success. But there are some practical techniques, many of them non-technical, that can dramatically improve a project’s chances.

In this, and in the next couple of postings of Business Analyst Times, I will lay out techniques based on observations from my own personal experience that I know can reliably produce excellent results. In combination, they can result in what is experienced as a “perfect project”. I present from more of a project management perspective rather than pure BA one, because my experience has been that management activities and decisions tend to impact projects, for good or ill, more than technical ones. The ideas that follow are in approximate order of importance. They are necessarily quite brief, and each one is expanded in future postings. 

1. Keep the project as small as possible. A project’s size is inversely proportional to its chance of success. As people are added to a project, the potential number of interactions increases pretty much exponentially, and things fall through the cracks, often catastrophically.

2. Carefully select a leadership team comprised of a project manager and key business and systems analysts. They must be highly qualified technically and must work together well as a team.

3. Create a partnership relationship with the customer. To improve the project’s chances of going smoothly, these two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative.

4. Limit formal processes and documentation to a minimum. “Big Process”, as exemplified by CMM/CMM and the IEEE standards can get in the way of a small sized project with high quality, motivated people.

5. Work intuitively. Operate at least partially in the mode exemplified by the Agile Methodology. By being highly flexible and willing to change as users are exposed to the emerging system, the probability of system acceptance is greatly increased.

Anyone who has been around a while knows that the conditions for achieving the perfect project are not commonly present. But, if they do exist where you now are, or you can influence things to cause them to exist, then enjoy your perfect project.

Keep Project Size Small

My experience has been that project size, in terms of the number of people working on that project, is inversely proportional to its chance of success. I have been around several projects that had 100+ staff. While none of them outright failed, none of them came out particularly well. In one instance, a literal handful of people (myself included) redid one of those large systems in a year of intense work, and turned a mediocre system with poor performance characteristics into a roaring success.

Why do large projects have problems? In a nutshell, the active principle is project communications. As people are added to a project, the potential number of interactions increases pretty much exponentially. The result is that important communications don’t always get to all necessary recipients, and things fall through the cracks. Mistakes are made, and they can prove to be disastrous. People feel isolated, morale tends to be poor, and turnover is high. Big projects try to mitigate this by requiring huge amounts of formal documentation and by holding many, many meetings. The sheer mass of material makes it nearly impossible for individuals to read everything they need to read to stay up to speed on everything that might affect them. It also becomes almost impossible for any one individual to comprehend the full documentation set as a whole, meaning that there may be no one individual who understands the entire project.

Any project that has more people than can fit around a large conference table is going to experience degraded performance due to communications issues. Conversely, with a small team, any communications issues can be addressed face-to-face and be observed by the entire project team. Much can be done on an informal basis that would otherwise require formal process and documentation. For instance, the two persons responsible for both ends of an interface can sit down at a whiteboard and work out the interface, and then, instead of creating a formal Interface Control Document, they just send an email summarizing the design. When it comes time to test the interface, both parties can be present and can troubleshoot and fix any problems on the spot. I know this works, because I have done it.
 
A small, closely knit team of sharp people can work miracles. I have been lucky enough to have worked a few myself. I claim that with such a team, working informally and without undue process and documentation overhead, I can build a given system faster, with better quality, and with better user acceptance than can be done by your average 100-person team, working under what is considered best practice processes.

Some projects are just too big functionally to do them with a single small team. This is especially true if hardware and communications must be procured and integrated, facilities must be built, and national security data is involved. But it may be possible to cleanly partition the problem into a set of functions that can then be implemented using a set of closely cooperating small teams, with a top-level team comprised primarily of team leads. Each team then operates independently on its functional area, and the top-level team ensures that cross team issues such as interfaces get handled efficiently and effectively.

© Copyright John L. Dean, 2008.

Look for Part 2 of Road to the Perfect Project in the next Business Analyst Times

John L. Dean is an IT professional whose long and broad experience base gives him an unusual perspective on what does and does not work. He has 40 years experience, mostly in government IT contracting, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked on both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and more recently has worked as an independent consultant. John has a Masters degree in Operations Research from Clemson University. He can be contacted at

[email protected].

Defining Value to Prioritize Features

Written by Cynthia Low on . Posted in Articles. 1 Comment on Defining Value to Prioritize Features

Building The Right Thing

One problem with software development methods these days is that there are a lot of different ideas on the right way to build things, but we don’t have too much guidance on how to make sure we are building the right things. There is plenty of advice on the best techniques to develop quality software, but all of this guidance is based on the assumption that the team already knows what they are supposed to be building. When it comes to how to find that out, just about every methodology has the customer/stakeholder/product owner prioritize the features/use cases/user stories.

Great, but do our stakeholders always know a sure fire way to properly define what is the most important aspects of a product or system. Do they always have an objective understanding of whether the product or service should be created or updated in the first place? All too often, stakeholders don’t have a clear idea of how to determine if they are asking for the right thing, and the project team doesn’t necessarily help them.

So what does it mean to build the “right thing”? Well, one way to look at it is to understand:

  • What projects should the organization undertake? 
  • What features should be provided for those products or services? 
  • What order should features be delivered?

So how do project teams “do the right thing”? It comes down to the project team, including the stakeholders, working together to understand the organization’s definition of value, applying that definition to determine the value delivered by their projects, determining how the features contribute to the project’s value delivery, and prioritizing the features accordingly.

We’ll discuss each of those steps in turn. One thing to note that whenever I say project team, I include stakeholders in that grouping, and I use stakeholders interchangeably with customers, product owners, users, goal donors, and gold donors.

The Organization’s Definition of Value

Value is one of those words that, while easy to define, often means different things to different people, especially when used in the context of software development projects. The most appropriate dictionary based definition is: “relative worth, utility, or importance.” (http://www.merriam-webster.com/dictionary/values). When you consider this definition, it is easy to see why the definition of value will vary between different organizations. It just so happens that an organization’s strategy, as expressed by its strategic decision filters, provides a definition of value. Strategic decision filters basically provide simple rules to determine which activities create and support sustainable competitive advantage, and which activities detract from an organization’s maintaining its competitive advantage. Anything that creates and supports the organization’s sustainable competitive advantage inherently is valuable to the organization.

The Value Delivered by the Project

Once the project team understands what is valuable to an organization, they can establish a value model for the project, which provides the project team with a tool to repeatedly assess the value delivered by a project.

The value model has four key inputs:

  • Purpose. A statement about what problem the project is trying to solve, or for those optimists out there, the job that the project is trying to get done.
  • Considerations. All those aspects of the project that could impact the value produced by the project, but are either too difficult to quantify, or haven’t happened yet, such as risks, issues, assumptions, and constraints.
  • Cost. The financial resources required to undertake the project, including such things as the people working on the project, hardware, and software.
  • Benefits. The positive impact the project has on the organization. Benefits can be financial in nature, such as increased revenue or reduced costs; or non-financial, such as support for other initiatives, or improved customer satisfaction. It is a good practice for the project team to collaborate on the purpose of the project first and run that purpose through the organization’s strategic decision filters. If the project fits within those filters, the project team can then continue to understand the remaining inputs. If however, the purpose of the project does not pass the strategic decision filters, then work on the project should stop, as it will most likely not deliver any value to the organization. Of course, if the result of the effort to evaluate the project purpose against the strategic decision filters results in the question, “what strategic decision filters?” then the organization has some more fundamental work to do.

If the project is a strategic fit, the project team then collaboratively identifies the considerations, costs, and benefits of the project and crafts a model to determine the value delivered by a project. This model should be built in such a way that it can be quickly updated and analyzed throughout the life of the project as considerations change, costs are better understood, and the benefits produced become clearer. The advantage of this approach over the typical practice of developing a business case to justify the project and then never reviewing it again, is that the project team is able to determine if the project is on track to deliver the expected value, or if conditions have changed such that the project no longer makes sense to continue.

Feature Contribution to Value

Once the project team has a grasp on how the project adds value to the organization, they can start analyzing how the various features under consideration contribute to the overall project value delivery. This can be difficult because the size of feature that delivers discernable project value is often different than the level at which the project team is comfortable fully defining features. A solution to that problem is to group finely grained features into the smallest grouping that delivers value to the stakeholder. Mark Denne and Dr. Jane Cleland-Huang introduced this concept and called them Minimal Marketable Features (MMF) in their book Software By Numbers (http://www.softwarebynumbers.org/default.htm).

 Project teams can organize their features into MMF and then, through an understanding of the relative value of those MMF’s to the overall project, prioritize the features delivered by terms of relative value contributed to the project. This approach is especially effective when the project team is following an iterative approach to development, when subsets of the overall feature set included in a project are delivered on a regular basis. Ideally, project teams will find themselves in a situation where they are able to identify a financial value delivered by a feature, but this is the exception rather than the rule. More often than not, project teams have to express the value in relative terms compared to other features included in the project. Regardless of the measure used, whether it be hard dollars, or a unit of less relative weighting, the key is for project teams to have some understanding, objective or subjective, of the value each feature contributes to the overall project and use that value as the basis for prioritization decisions.

Really Analyzing the Business

What I have just described is business analysis at its finest. It goes beyond simply “gathering” requirements to truly developing an understanding of the business, the problem that needs to be solved, and the benefits of the solution to the overall organization. This approach requires a great deal of collaboration between all involved in a project, especially business analysts, who should have the appropriate skill sets to facilitate the creation and revision of the value model, and the application of that definition of value to the features included in the project. A business analyst who has these skill sets is truly setting themselves up as an invaluable person to their organization.

Kent McDonald

is a Business Systems Coach with Knowledge Bridge Partners and Partner in Accelinnova, http://www.knowledgebridgepartners.com. He has more than a decade of experience guiding successful projects and designing business solutions in a variety of industries including financial services, health insurance, performance marketing, human services, non profit, and automotive. His background includes delivering data-intensive and web-enabled application development projects that provide outstanding business value. He has coached client staff to help teams reach project goals more productively and effectively. Kent is a speaker, writer, and coach on project leadership, business analysis, and delivering business value through projects. He can be reached at [email protected]

The Business Analyst as Strategist

Written by Kathleen B. Hass, PMP on . Posted in Articles.

A recent survey conducted by Evans Data Corporation, The New Business Analyst: A Strategic Role in the Enterprise, found that business analysts are key players in making strategic decisions. “A clear line in the corporate sand has been drawn as to the importance of the business analyst. The BA plays an increasingly integral and strategic role in organizational success,” said Evans Data Corporation President John Andrews. Business analysts are emerging as the central business competency of the future. Different from systems analysts or project managers, business analysts (BAs) not only manage project requirements, they also contribute vital information to strategic planning, goal setting and strategy execution. It is in this capacity that BAs can have the greatest impact on the long-term success of the enterprise.

Business Analyst as Master Strategist

In their Body of Knowledge, the International Association of Business Analysts (IIBA) defines a BA as someone who “works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”

To help distinguish the roles played by the BA and the project manager, consider an analogy from the world of sports. On a football team, the coach (the project manager) is given a game (the project) with requirements (to win), as well as team members and resources (players and equipment). But what happens when the requirements change? The team owner feels it’s not enough just to win games, and the goal is now to win the Super Bowl. Enter the general manager (the BA). Responsible for the team’s overall strategy for success, the general manager continually validates that the project team is focused on the strategic imperatives. Similarly, the BA keeps her eye on strategic-level decisions that impact the project, leaving the project manager free to focus solely on optimizing project team performance.

No analogy is perfect, of course. In football, the coach reports to the general manager, but in business, the BA and the project manager share leadership of the project team. Much like a general manager, however, the BA keeps track of the overall direction of the team’s season, freeing the project manager to “get in the huddle” with the team and direct it on a play-by-play basis.

Specific Strategic Planning Tasks

Of course, the BA is not the only one on the project team familiar with the strategic goals of the organization. Employees perform best when they understand their organization’s plans and their role in them. One vital role for BAs is to translate strategies into new proposals for the company, as well as to ensure existing operations mesh with the strategy. In fact, all proposals for organizational change should be aligned with corporate strategies, and the BA is best suited to handle the enterprise analysis needed to ensure alignment.

The BA must have a thorough understanding of the organization’s strategic goals to facilitate the process of matching project objectives to business needs.The BA assures the project deliverables meet the business needs and helps to realign the project when requirements change. BAs makes certain that throughout their life cycle, projects continue to meet business needs and deliver benefits that outweigh their costs. Because of their familiarity with the organization’s strategic goals, the BA is often adept at securing additional support from the business sponsor, if needed. At the end of the project, the BA examines the ROI to determine if the project met its goals.

The BA can also be a valuable provider of information to the strategic planning team or top-level management. BAs may perform analyses of the competition, gather customer feedback and complete benchmark studies to support a business case or project investment decision package. In addition to providing data for decision-makers, senior BAs may also conduct goal setting meetings and even help conduct strategic planning sessions.

A Vital Role

Just how important is the strategic planning role that is filled by the BA? Judging from the poor success record of projects in the business world, very important. Consider these statistics:

  • $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)
  • 25 percent – 40 percent of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
  • 50 percent of projects are rolled back out of production (Gartner)
  • 40 percent of problems are found by end users (Gartner)
  • Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66 percent project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)
  • 60-80 percent of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
  • Nearly two thirds of all IT projects fail or run into trouble. (See Figure 1 for the results of the 2006 CHAOS Survey.)


Figure 1: Project Performance Track Record – The Standish Group 2006 Chaos Report

Until the creation of the professional BA, there was no one person responsible for ensuring that business requirements were accurately determined and managed throughout the lifespan of the project. Business sponsors often do not have the time or the technical expertise to provide oversight to projects on a day-to-day basis, and their role is best left to securing funding and resources and using their authority to help effect institutional changes in support of the project. Project managers are focused on delivering what was asked of them within time, cost and quality constraints, not constantly reevaluating and validating the business need.

The Future

The high-velocity change occurring in the business world today requires more than employees capable of completing assigned tasks. It calls for multi-skilled practitioners who are systems thinkers, comfortable in both the boardroom and the server room. As they seek to increase project success rates, more companies will include business analysts in their project teams, recognizing the added strategic value they bring to the table.

Building a BA Centre of Excellence.

Written by Glenn R. Brule on . Posted in Articles.

Where to Start and What to Consider
 It strikes me as odd that, given the number of clients I have dealt with over the years, there remains a constant assumption that, because you provide training to a group of individuals in any given organization, you, by right of passage, become a “mature” practicing organization.   Get them together on an individual basis, however, and any one of them would tell you quite the opposite.  Disarray is perhaps the most fitting descriptor for this case.
We are always willing to acknowledge that which we continuously seek, industry standards. Sadly such industry standards are nowhere near where we want them to be.  Take, for example, the Chaos Report developed by the Standish group.  It maintains that, of all the projects it assesses in North America, only 34% of them would expect to finish on time, on budget and within the original scope defined.  ESI clients have shared with us in a recent survey the fact that the number one challenge in turning requirements into deliverables is poor requirements definition, followed by improper risk management and finally, scope creep.

 Why are our projects in a state of disarray?  It’s likely not the project management practice. Most organizations have a well-defined PMO and all the disciplines have been identified to conduct their day-to-day activities.  It is business analysis and the lack of structure, discipline and rigor around its day-to-day activities that, I believe, is the traceable root cause of project distress.

 It’s the situations where we have no formalized process for eliciting, analyzing, documenting, validating/testing, and tracking our requirements.  I’ve seen it time and time again where great degrees and variations of the above exist.  Organizations have 47 flavors of Business Requirements Document templates and they call this a standard. Their corporate solution development lifecycle gets hacked down, expanded, massaged, and tailored to meet a particular business unit’s need, and again we call this a standard. Methodologies are adopted and then tailored or crafted according to need or thought de jour!

 Another area of weakness: how can our resources possibly be expected to deliver with any degree of accuracy if we are not even clear on the tasks and activities that need to be performed to achieve the desired results?  Even more seriously, there is no linkage to our “standard methodologies.” As such, we insist on sprinkling the “magic fairy dust” over unsuspecting subject matter experts, and with a mighty push out the door in the direction of our stakeholders, who “don’t know what they don’t know,” expect them to achieve great results. Tell me that’s not a problem waiting to happen!  The other very interesting situation that continues to present itself where competencies and career definition are concerned, is that organizations continuously expect that PMs and BAs can perform each other’s given tasks.  Our resources are stressed out, and being asked to do more with less, in a shorter period of time. Clearly this need for speed is not working in our favor.

 It’s interesting to note that, while we would all acknowledge and recognize the errors of our ways, the real error is not being able to identify a starting point from which we can begin the process of maturing our BA practice. In a world where our daily activities are under constant scrutiny, I find myself repeating an old Japanese proverb “vision without action is a daydream and action with vision is a nightmare!”  The question still remains: where do we start?

Three things must be considered. 1) Have a plan, 2) Be patient and 3) Know your capabilities.  To have a plan, a project plan, means that, to some degree, you have considered the scope of what it is you and your team are about to embark upon. You clearly understand the major tasks and deliverables, and the time frame in which to accomplish such goals. Tactically, all tasks and activities that need to be accomplished to fulfill the needs of a developing Center of Excellence (COE) are easy to accomplish. Strategically, a cultural shift will not happen overnight, as a change in business practice must be carefully nurtured over a period of time, so we must be patient. Knowing your capabilities will allow you to understand the scope of what it is you are about to undertake. Being honest about the true level of maturity will allow the sponsoring organization to focus on the priority issues. Not all problems can be solved at once, even using advanced “technologies, thoughts and process.” For example, if it is understood that your organization is in its BA development infancy stage, why apply the most complex formulas to begin your baseline metrics. You must walk before you run.

Any good project manager or business analyst will tell you that, without active support, input and feedback, your initiative may be all for naught. Consider your stakeholders with thoroughness.

  • The Executive Team:  The strategic decision makers
  • Executive Sponsor:  May or may not be the same individual or individuals, but essentially hold the budgetary and resource means by which you will accomplish your endeavour
  • BA Director/Manager or Supervisor:  This individual will serve as the liaison between the tactical and strategic sides of the endeavour; they will be ultimately responsible for managing and maintaining the COE.
  • BAs:  Get them involved! Give them a sense of ownership; have them solve some of the challenges facing the organization; select a team of champions that represent the diversity of the BA group. After all they will be on the frontlines!
  • Project Managers:  Without requirements there are no deliverables. Without deliverables requirements have no meaning. This is a mutually exclusive relationship, and should be treated as such. Not including the project managers will encourage a siloed/ independent approach to the delivery of projects and alienate team members. Also consider that much of the structure and foundation of how PMOs evolved can be used as lessons learned for the development of a BA COE.
  • Functional Managers: There will come a time when the COE will have to engage the functional managers to provide additional resources for the definition and creation of requirements. As such, the borrowing of resources should not be impeded by a misunderstanding or lack of knowledge of what the COE’s purpose is.
  • Customers: Frequently, customers can be heard complaining about analysis paralysis, and are more focused on the outcome rather than the process used to get there.  It is the lack of knowledge and appreciation of this that is important to share with clients. Their feedback and assessment of the performance of the COE will be critical to its growth.

Have a plan, be patient and know your capabilities.

Levels of Maturity: Ask any organization and fifty percent of the time they tell you flat out that they are mature in their BA practices. They tell you they have three standard methodologies, and did some training, “our people are very competent” and, therefore they are operating at a Center of Excellence capacity.  The reality is this: while it may be true that investments are made to develop resources and put into place tools and methodologies this by itself does not constitute excellence.  The sum of all parts and the practice of organized and disciplined business analysis over a period of time constitutes maturity.  For the sake of this article, I have defined three possible levels of BA maturity. The titles themselves are arbitrary and may be changed according to the requirements of the sponsoring organization. It is the classification and characteristics of each level of maturity that will provide the needed assessment and guidance for development.

 

Level I – Community of Practice

Most organizations today are performing business analysis at a community of practice level.  They have recognized the need to develop the skill sets of their BA resources, and may have even gone as far as doing an assessment and evaluation of the level of competency of their BA group. As such they were able to identify any gaps that might exist in both performance and overall competencies and job descriptions.  Other organizations have also begun to put into place a solution development lifecycle and are likely to be in the process of either redefining or developing one.  A common question that comes up is this; what do we develop first, the people or the processes?  My response is go with the egg, eventually the chicken will come!  The processes need to define what needs to be done, and how it will be done, in the context of an SDLC. Job descriptions must define the ability, skill and knowledge necessary to perform the tasks and activities defined in the SDLC. The solution development lifecycle and job descriptions/career paths and competencies must be closely interrelated. They may begin to demonstrate an alignment with the PMO.

An overall acknowledgement by the organization of the role of the business analyst and its importance to the success of overall project deliverables is beginning to form. At this point our services, if sought, perceived as being reactive in response to an immediate need, and generally sought after as a utility. At this point, our accomplishments are only beginning to have any real recognition at the middle management level because of the tactical nature of our services.

Level II – BA Bureau of Maturity

There is no doubt in my mind that many organizations have demonstrated in some capacity their level of maturity given a specific area with the guiding principles in level of maturity. They may include some of or all of the following items, but in order to move from one degree of maturity to another demonstration of the following with consistency over a period of time is necessary.  A direct reporting structure to either the PMO or the CIO may be in place a Director of the BAB is likely to be the leader of the BAs and as such is making strides to present his team as a distinct business unit. The team is clearly a distinct pool of resources.  From a services perspective they are beginning to show signs of credibility amongst the business unit leaders as a result of consistent performance excellence. Business Unit Leaders are seeking out the team to provide assistance when needed, and the recognition of moving from a tactical to strategic role is beginning to form.

Level II – Center of Excellence

You’ve developed partnerships with the executive. Your team is sought after as the change leaders of the organization. You are clearly recognized as a customer service solution. You and your team have demonstrated your discipline both tactically and strategically. Most importantly, you have clearly defined the art of Enterprise Analysis (EA) and demonstrated your ability in the five areas of EA including, Business Architecture, Information Architecture, Application Architecture, Technology Architecture, and Security Architecture. Your team is providing and sponsoring studies to participate in overall corporate advanced and BPI & KPI’s and overall business effectiveness.  Your continuous assessment and evaluation of performance on internal process and customer satisfaction has become commonplace.

There are two keys to clearly understanding your level of maturity with the presented model. Acknowledge that it is likely that your organization may demonstrate maturity at a variety of levels given this framework. Also consider that true excellence must be demonstrated and evaluated as consistent over a period of time. As an example, training may be delivered in order to move the organization into a Community of Practice / level one of maturity. Training and learning do not stop here. Certification, coaching and mentoring, participation in improvement initiatives, and membership in organizations such as the IIBA, are the contributing factors that move an organization from one level of maturity to the next. In short, the sum of the parts is equal to the whole!

Glenn Brûlé, Director of Client Solutions for ESI International, has more than 15 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn’s background as an educator, communicator and business consultant has served him well through his many client engagements that have focused on understanding, diagnosing and providing workable business solutions to complex problems.In addition to his position at ESI, Glenn serves as a Director at Large for the International Institute of Business Analysis (IIBA). His primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries and government agencies. Glenn has successfully launched eight chapters in major Canadian cities and is currently working on launching eight more U.S. chapters and nine outside of North America. Glenn Brûlé is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World, Congress for Business Analysts and IIBA events. He has authored numerous articles on business analysis and was instrumental in the development of ESI’s white paper titled “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies.”  

 
Watermark Learning Reports Increased Demand for Business Analysis Training

 As awareness grows in the project management industry, demand is increasing for business analysis training, since business analysis is frequently cited as a key problem area for providing inconsistent deliverables. As a result, companies such as Allianz Life have established a Business Analyst Center of Practice to ensure that their business analysts have the framework, processes, skills and techniques to excel in their profession.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life.

 “In today’s competitive landscape, businesses must perform with razor sharp efficiency and productivity,” said Terri Swanson, Watermark Learning, COO. “More business leaders are recognizing the value that business analysis training brings to an employee’s contribution and the effectiveness of an organization as a whole.”

 Since launching the Masters Certificate in Business Analysis in July 2005, Watermark Learning has received hundreds of participants in the program, including Allianz Life, a life insurance company.

 Allianz Life identified the business analysis process as their key problem area providing inconsistent deliverables. They established a Business Analyst Center of Practice to ensure that their business analysts had the framework, processes, skills and techniques to excel in their profession. As part of this initiative, Allianz Life looked to partner with a training vendor who could provide a professional business analysis certification program based on industry best practices, designed to specifically address their business needs.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life. “Not only will our business analysts receive a Masters Certificate, but they will also gain Professional Development Units through PMI as well as CEUs through Auburn University.”

 Watermark Learning is actively involved in raising industry awareness of the value of business analysis and was named an IIBA Endorsed Education Provider. It’s principals and founders, Elizabeth Larson, PMP, and Richard Larson, PMP, have helped develop the Business Analysis Body of Knowledge (BABOK), a document created to identify the key tasks that a business analyst would be expected to understand and perform