Tag: Project Management

A First Pass at Defining the BA/PM Position Family

Written by Cynthia Low on June 16, 2008. Posted in Articles.

In the previous article I set forth and compared the skills profile of the Business Analyst and the Project Manager. That was a very high level comparison. In order to get down to the practice level proficiency, it is necessary to define the BA/PM Position Family. That is the intent of this article. Recognize that this is my opinion and has not been discussed with any of my business analyst or project manager colleagues.

The responses to the first three articles have been overwhelming. They have been both positive and negative. Being a change management advocate, I am pleased with your reactions. My hope is that we can continue the exchange. As always I welcome opposing positions and the opportunity to engage in public discussions. Your substantive comments are valuable. Criticism is fine and is expected but, in the spirit of agile project management, so are suggestions for improvement.

I realize that I have taken a controversial position and I do so intentionally. At least I have your attention whether you agree with my position or not.

Professional Development of the BA/PM
In the previous article I offered a first pass at defining the BA/PM position family. I see that family as consisting of the following six positions:

BA/PM Team Member
BA/PM Task Manager
BA/PM Associate Manager
BA/PM Senior Manager
BA/PM Program Manager
BA/PM Director

Let me offer the next level of detail for each of these positions. Years ago I had the opportunity to consult with the British Computer Society on the development and implementation of their Professional Development Program. A few years later I had the occasion to develop an internet-based decision support system for IT career development for one of my clients. That system was called CareerAgent. In this article I have integrated that model into the earlier work for the British Computer Society. Much of what I define below takes advantage of the deliverables from both of those engagements. The result is the graphic shown below.

Figure 1: The Project Manager and Business Analyst Landscape

Figure 1 is interpreted as follows. The extreme left and right vertical sectors identify those professionals who are either pure project managers (PM) or pure business analysts (BA) with the accompanying skills and competencies needed for their positions. All of the sectors in between are professionals having some combination of project management and business analyst skills and competencies. For example, as you move from the PM to the PM/ba sector you identify professionals who have pure project manager skills and competencies plus some business analyst skills and competencies. Most project managers would have some business analyst skills and competencies. Project management remains the primary focus of their position. The same interpretation holds for the BA/pm sector. The primary focus of their position is business analysis and many business analysts have some project management skills and competencies. In the middle sectors are the PM/BA and BA/PM professionals. These are the professionals that I have been referring to in all the preceding articles. They are fully qualified to manage projects and manage business analysis engagements. Their skill and competency profiles are equivalent. Their primary orientation is either as a project manager (PM/BA) or as a business analyst (BA/PM). I believe that the major career opportunities are for the PM/BA or BA/PM professionals.

The rows of this landscape refer to the six levels in the position family. At the staff level there are two positions. At the entry level are the Team Members. These professionals will have an entry level skill and competency profile that qualifies them to be a team member in a project (PM) or business analysis (BA) effort. As they gain experience they will move up to the Task Manager level where they will be qualified to supervise the work of a task, perhaps with the support of other team members. At the professional level there are two positions. The lower of the two is the Associate Manager. These positions are qualified to manage small, simple projects. Through experience they progress to the Senior Manager level. They are now qualified to manage even the most complex projects. The Director level positions are of two types. One is the Program Manager. This position is both a consultant-type position as well as a manager of project managers working on a program – a collection of projects having some relationship with one another. The other position is the Director position. These are people management positions. They are the highest level of the six position family.

Using the Landscape for Professional Development
Each cell in the landscape will have a minimum skill and competency profile defined for all positions in that cell. In order for an individual to be in this cell, they must possess the minimum skill and competency profile for the cell that they occupy, or would like to occupy. For professional development planning, the individual will be in some particular cell and have career aspirations to move to another position in the same cell, or to a position in another cell (usually this will be an adjoining cell). The skill and competency profile of the current and desired positions or cells can be compared and the differences will identify the skill and competency gaps. The training and experience needed to remove that gap and be qualified to move to a position in the desired cell can be defined. The implications to the training department planning are obvious, as are the applications to human resource management.

What Might a Professional Development Program Look Like?
This is a big topic. By way of introduction I think that a good professional development program should consist of the four parts briefly defined below

Experience Acquisition
Further experience mastering the skills and competencies needed in the current position
On the job training
Training to increase the proficiency of skills and competencies needed in the current position
Off the job training
Training to increase the proficiency of skills and competencies needed in the desired position
Professional activities
A combination of reading, professional society involvement, conference attendance and networking with other professionals

Every position in every cell will have a minimum skill and competency profile required for the position. To qualify for a specific position the individual must first define the skill and competency gap between their current and desired position and then build a professional development program using the above four components to remove that gap. That would position the individual to move to the desired position when a vacancy arises. Each individual should have a mentor assigned to them to help with plan development and other career advice.

Putting It All Together
Obviously this is a work in progress. It has been done for the IT profession but not for the BA/PM professional (or PM/BA if you prefer). Much remains to be done. I would certainly like to hear your thoughts on the BA/PM professional or PM/BA professional, if you prefer. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles. You may reach me directly at [email protected].

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

The Debate Over Blending the Roles of the BA and the PM

Written by Richard Lannon on May 15, 2008. Posted in Articles.

In the last Business Analyst Times, Bob Wysocki suggested that, in this day and age, the business analyst and the project manager have much in common with major areas of overlap. He pointed out that the skill and competency profiles of the effective BA and the effective PM are virtually identical. He argued that possibly a new role will emerge combining the competency of both. Boy, did that set the fur flying! As a result, we’ve created a dedicated discussion forum for you to participate in. To go there now, click here.

Part two of Bob’s series, Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM, is in this issue and we invite you to read it and react by contributing to what is an ongoing and, at times, heated discussion.

Contributor Richard Lannon brings his experience in facilitating Information Technology Service Management (ITSM) work sessions in the energy sector to helping IT organizations improve processes and services. He stresses the importance of looking at situations from a broad business perspective rather than a narrower IT viewpoint. In his article, ITSM Work Sessions: Lessons Learned, Richard shares the lessons he’s learned over the years and how to put them to work.

Bloggers John Dean and Terry Longo are back. John shares his views on setting up identity systems, while Terry wonders should the BA be part of the IT department or have a broader role within business.

I know you have your own views – I’ve heard some of them on the road. Please share them with other Business Analyst Times readers.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

Is it Time for the BA and the PM to Get Hitched?

Written by Cynthia Low on April 30, 2008. Posted in Articles. 1 Comment on Is it Time for the BA and the PM to Get Hitched?

My life as a project manager (PM) began in 1963 at Texas Instruments at about the time IBM announced System 360. It was a landmark event in the history of computing and little did I know at the time but it was also the wakeup call that a revolution was about to take place. It was a revolution that we weren’t ready for. If I remember correctly I ran projects but was called a systems consultant. I don’t recall anyone in my industry carrying the title project manager. There was very little in the way of tools, templates and processes to support me. The only software that I knew about was an old IBM1130 program that I think was called Process Control System. One of my friends in the building construction trade introduced me to it and I thought I was now king of the hill. PMI wouldn’t arrive on the scene until 1969.

As for the business analyst (BA) they weren’t around, at least not by that name. What we did have were computer professionals that were called systems analysts. They were the mystics from the IT Department who could talk to a businessperson about what they wanted, retreat into their space to concoct a solution, emerge to tell the programmers what to build and then hope for the best. Few clients were satisfied with the results but they weren’t involved enough to know what to do about it. Life was tough in those early days of project management and systems development. Clients were kept at arm’s length and only got involved when it was time to sign a document under the threat of a project delay if they didn’t sign. Every one of my colleagues, including myself, was looking for silver bullets.

Fast forward to 2008. The systems development landscape is more mature as are the life cycles employed. We have linear, incremental, iterative, adaptive and extreme projects. In less than 40 years PMI has grown to over 250,000 members worldwide. It is the de facto professional society for PMs. IIBA, launched in 2003, is just getting started and has a membership of over 4,000 worldwide. Size differences aside the two organizations have a lot in common and a lot to gain through collaboration and joint ventures.

The major area of overlap is requirements gathering and management. Both the PM and the BA face the same challenges here. Even under the best of circumstances it is very difficult, if not impossible, to identify and document complete requirements. The reasons are many and well known to both professional groups. Underlying it all is the need for more collaborative efforts.

The next area of overlap is process improvement. In the world of the PM and their management this means applying some variation of the Capability Maturity Model and continuous project management process and practice improvement. For the BA this means business process improvement projects and that means having effective project management methodologies.

The next area of overlap is the skill and competency profile of the effective PM and the effective BA. The two profiles are virtually identical. Some have posited that we really don’t need both types assigned to the same project. We could certainly debate that point of view but, if present trends continue, I would argue that a single person, whatever label you choose to use, will soon be sufficient. In other words the BA should have the requisite skills and competencies to be an effective PM and the PM should have the requisite skills and competencies to be an effective BA. They will have morphed into one professional. Lacking an appropriate name right now, I’ll refer to this single professional as a BA/PM. We are not too far away from that day.

The next area of overlap is the processes, tools and templates that both professionals follow. Again they are virtually identical at the concept level.

I could go on but I think you get the picture. I am led to the conclusion that the support of both the PM and the BA should lie in a single organizational entity that I am going to call the Business Project, Program, Portfolio and Process Office or BP⁴O for short. Please excuse my taking liberties with the multiple use of “P”. I do that for good reason. PMs have had the Project Management Office (PMO) under various names for a number of years. The BA has not had a similar support organization. Recently I have seen Communities of Practice (COP) and Centers of Excellence (COE) emerging for the BA, but these are more voluntary forums for the BA to network and exchange ideas with their peers than an organized business unit. There is no valid argument that can be given for not expanding the PMO to embrace the BA. That is what I am calling the BP⁴O and that is the focus of the remainder of this article.

The World Class BP⁴O

On the surface the world class BP⁴O won’t seem much different than the traditional PMO. The world class BP⁴O offers an expanded portfolio of support functions as compared to the typical PMO but if you look under the hood, you will see that I am proposing that there be a significant difference. In organizations that see the handwriting they see that project management, program management, portfolio management and business process management are all converging on a single strategic role with enterprise-wide scope. The world class BP⁴O that I envision is a central participant in that role. It helps define strategy and through its infrastructure provides for the enablement of that strategy too. And so here is my first shot at a definition of the world class BP⁴O.

Definition of the World Class BP⁴O

The world class BP⁴O is an enterprise-wide organizational unit that helps formulate and fully supports the strategic, tactical and operational initiatives of the enterprise. The world class BP⁴O is characterized by:

Led by the VP BP⁴O who has a voting seat at the strategy table
Fully participates in the formation and approval of the business plan at all levels
Establishes the processes for and monitors the performance of the project portfolio
Has authority and responsibility to set priorities and allocate resources to projects
Establishes standards for the tools, templates and processes used by BAs and PMs
Monitors compliance in the tools, templates and processes used by BAs and PMs
Establishes an integrated BA/PM position family with defined career paths
Provides a complete program (training and human resource management) for the professional development of all BA/PMs
Assures that the skill and competency profile of the BA/PM staff is sufficient for the realization of the project portfolio
Allocates BA/PMs to the approved portfolio of projects
Offers a full range of support services to executives, sponsors and project teams
All BA/PMs have an approved professional development program.
Performance metrics:
- The project management and business process methodologies are assessed at CMMI Maturity Level 5
- On average the practice maturity level is at least CMMI Maturity Level 3
- The project failure rate is less than 10%

As you can see the VP BP⁴O is an integral part of the enterprise from the strategy formation level to tactical planning to execution at the operational level. It is that unit’s responsibility to make the most effective use of the enterprise’s human resources towards the realization of the business plan.

Mission of the World Class BP⁴O

To provide a comprehensive portfolio of strategic, tactical and operational support services to all project teams, sponsors and executives in order to assure the delivery of maximum business value from the project portfolio.

Objectives of the World Class BP⁴O

Define a project life cycle with stage gate approvals.
Design, develop, deploy and support a comprehensive portfolio of tools, templates and processes to effectively support all projects.
Design and deploy a project review process to support project teams and monitor compliance to established standards and practices.
Establish a project portfolio management process to maximize the business value of project investments.
Establish a decision support system and dashboard to support executive management’s project decisions and provide for the timely monitoring of the project portfolio status.
Design, develop, deploy and support a comprehensive HR Project Management System.
Design, develop, deploy and support a continuous process improvement program for the BP⁴O.

Organizational Structure of the World Class BP⁴O

The only structure that makes sense to me is one where the BA/PMs are close to their client groups. That structure is what I call the “Hub & Spoke. At the Hub we have the enterprise level unit that is responsible for policy, process and staff development. At the Spokes are the various divisions and departments with their own staff of BA/PMs. They might establish tools, templates and processes specific to their needs but in compliance with the enterprise policies and processes.

Staffing of the World Class BP⁴O

There are five staffing models that come to mind:

Virtual BP⁴O

The Virtual BP⁴O does not have any BA/PMs assigned to it. Instead they are deployed throughout the enterprise where they are assigned on an as needed basis by their organizational unit. These are not fulltime project managers but are professionals in other disciplines who have project management skills and competencies as part of their toolkit.

The BP⁴O staff consists of a manager and one or more assistants who support BA/PMs as required. They may be BA/PMs but that is not necessary. The important thing is that this staff has the necessary expertise to provide the support needed. The support services may span the full list but are often quite restricted because of staff limitations.

BA/PMs are assigned to the BP⁴O on a rotating basis

This is an excellent model for deploying the BA/PM methodology, skills and competencies throughout the organization. In this model BA/PMs from the business units are temporarily assigned to the BP⁴O as a sabbatical from being on the firing line too long. A sabbatical might last from 3-6 months during which time they might conduct a specific process improvement project or simply act as mentor and coach to other BA/PMs.

BA/PMs assigned to the BP⁴O

In this structure the BP⁴O BA/PMs manage critical mission or enterprise-wide projects. Usually not all BA/PMs report to the BP⁴O. There will be several who are assigned to business units to work on less comprehensive projects for their unit.

BA/PMs assigned at the division level

BA/PMs assigned at the division level work on division-wide projects. These may be projects that span two or more departments.

BA/PMs assigned at the department level

Same as the division level except they are assigned within a department and only work on projects contained within their department.

Summary

This article is an opening gambit for me. My hope is to expand on some of the ideas expressed above in future articles. I hope that this article has provided food for thought and that you will take the time to let us have your comments.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3nd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Writing Effective Project Requirements

Written by Cynthia Low on January 31, 2008. Posted in Articles.

Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Importance of Requirements
Requirements are considered by many experts to be the major non-management, non-business reason projects do not achieve the “magic triangle” of on-time, on-budget, and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies, have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems, the most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

The requirements phase is also considered by many experts to be the most difficult part of any project due to the following:

The requirements phase is where business meets (IT) information technology.
Business people and IT people tend to speak different “languages.”
Business: “It has been determined that if we convolute the thingamajig or maybe retroactive the thatamathing, our profitability may, if we are extremely lucky, rise beyond the stratospheric atomic fundermuldering.”

In other words, English is an ambiguous language, and we tend to speak and write in a manner that makes it even more ambiguous, convoluted, and unclear.

Building Valid Requirements
The requirements analyst truly is responsible for the failure or success of the requirements on a project. With that at stake, building valid requirements up front is crucial. The four steps to this goal are: elicitation, analysis, specification, and validation.

Elicitation
The term elicitation is the industry-accepted term for getting the requirements from the stakeholders. Elicitation, however, implies much more than just capturing or gathering the requirements from users.

The truth is, one of the surest ways to fail in requirements is to say to your users, “Give me your requirements,” then stand back and “catch” them.

Why doesn’t this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.

So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.

The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

Analysis
Analysis involves refining (or analyzing) the stakeholder requirements into system, then software requirements. Analysis is a critical step, that is too often omitted or bypassed in projects.

Analysis is the critical transition from stakeholder or business terminology, to system or IT terminology. For example, stakeholders talk about “Monthly Marketing Report,” while systems talk about file “MoMktRpt.doc.”

Analysis involves brainwork, but it is not a magic process (nor is any other part of software engineering, for that matter). Analysis is usually done in conjunction with various modeling techniques. Modeling-creating diagrams using standard notations-allows analysts to more fully understand processes and data in a rigorous manner. This understanding allows them to convert the often non-rigid stakeholder requirements into more concise, rigid system and software requirements.

Common modeling techniques include the following:

Traditional systems
Dataflow diagrams to understand processes and activities
Entity-relationship diagrams to understand data
Object-oriented systems:
UML (Unified Modeling Language) diagrams, especially class diagrams for analysis, but also possibly collaboration diagrams

Specification
The specification sub-phase involves documenting the requirements into a well-formatted, well-organized document. Numerous resources are available to help with writing and formatting good requirements and good documents. For general writing assistance, books on technical (not general) writing should be used. A major resource is the set of IEEE Software Engineering Standards.

Validation
Once a requirements specification is completed in draft form, it must be reviewed both by peers of the author and by the project stakeholders in most cases. If detailed stakeholder requirements were written and signed off by the stakeholders, they may not need to participate in reviews of more technical system and software requirements. This presumes good traceability matrices are in place.

The specifications are reviewed by a group of people to ensure technical correctness, completeness, and various other things. Often checklists are used to ensure all requirements in all possible categories have been elicited and documented correctly.

Validation is actually a quality assurance topic. All documents produced throughout a project should undergo validation reviews.

This information was drawn from Global Knowledge’s Requirements Development and Management course developed by course director and author Jim Swanson, PMP. Prior to teaching for Global Knowledge, Jim worked 25 years for Hewlett-Packard as a business systems developer, technical product support, and senior project manager. Prior to HP, Jim worked as a Geologist for the US Geological Survey.

The Thin Line Between SME and PM

Written by Cynthia Low on December 17, 2007. Posted in Articles. 1 Comment on The Thin Line Between SME and PM

It isn’t uncommon for Subject Matter Experts (SME) to run or lead projects. In fact this tends to occur when the sponsor’s focus is on the conten, of the project. They often don’t really see the value of a separate PM role.

While it is vital to have a subject matter expert or analyst on a project, (as PMs should not be responsible for developing solutions) there are some subtle yet potentially costly risks associated with putting that individual in a dual SME/PM role.

It is human nature to focus our attention and efforts in our areas of expertise and, more often than not, this is what occurs. An SME is more likely to focus their attention on the details around the solution and to then go through the motions when it comes to the PM component of their role. This includes throwing together a project plan, because this is expected of the PM side of their role.

In my time, I have come across many SME built project plans and they contain some consistent findings. One is that the project plan always seems to end on the targeted project completion date, but the critical path cannot be calculated. This is usually because there are few if any dependencies built in. Instead the Start No Earlier Than (I call it the SNET) constraint is abused throughout the plan, obscuring the total slack.

So what? Well, while the solution may approximate perfection, the estimated time, effort and costs are unknown and likely based on a faulty work back plan. The project plan is simply window dressing, there simply to satisfy the sponsor and stakeholders’ need to see things appear to wrap up on time.

What results is often a project that overruns its scheduled time due to poor planning. Key resources, that may also cost dollars (IT resources or consultants), either disperse to other previously committed projects or must charge the extra time against the project, increasing the budget and lowering the return on investment.

In many cases this part of the job is severely neglected in favor of developing solutions. The other risk is that having an SME who is also responsible for the PM function is akin to having the fox watching the chicken coop. The PM role naturally provides the devil’s advocate to question the validity and assess the overall impact to the project’s success when change requests are introduced.

Scope creep cannot be properly managed without having an unbiased second opinion and a true assessment of the impact on the overall plan. This again leads to the perfect solution that will likely meet none of the requirements of the triple constraint. If getting to market on time is a key requirement, you need to have someone whose focus will remain on getting to market on time. SMEs are excellent at what they do which is why they perform this role. Their participation is vital to the project’s success. Excellence and perfection are the undying goals of a SME and rightly so. This is why they are at the table.

A PM’s role is to ensure that ALL of the objectives of the sponsor are being addressed, stakeholder expectations are managed, and that there is a high quality, regularly revisited plan in place along with the proper checkpoints and processes to address the unknown unknowns that tend to crop up at inopportune times.

Not all projects require a PM. As a rule of thumb, if the number of stakeholders and team members is small, the scope of the project is limited to one department (not an enterprise wide project) and time and cost is not an issue, you may be able to manage with a SME/PM. Once the scope of the project grows beyond this, your risks increase significantly unless you have a qualified and experienced project manager running your project.

The PM’s view of the project is much broader than the SME’s and project success means keeping your eye on all the moving parts of the project, including the solution.

Sean Best, PMP is a project management consultant and managing director of CRM Project Management Consulting. His 14+ years of project management experience includes work in the banking, payment processing, telecommunications and software industries. He can be reached at [email protected]