Skip to main content

Some Important Ideas To Help Keep Projects On Track

Editor’s Comments

As usual, we have an eclectic mix of articles and blogs, some from foreign parts, which we hope will fill you in on some of the ideas that are circulating in the project management community. We hope you’ll find them interesting and be able to apply some of them to your own upcoming projects.


  • Keeping Project Scope Creep under Control. Bruce Beer looks at the very negative impact that scope creep can have on a project and provides some thoughts to minimize it.
  • Project Success Factors and Value Contracts. George Konstantopoulos writes about the important tools that help keep a project on track and that can also help recognize the PM’s efforts at the conclusion of a successful project.
  • Hug a Business Analyst Today! David Barrett uses his blog, en route between Australia and New Zealand, to sing the praises of business analysts without whom, he says, the project manager’s job is much more difficult.
  • From Good to Bloody Excellent – Part 2 (How). In his monthly blog, Ilya Bogorad continues his series in which he outlines his views and the five key factors in establishing an effective project management office.
  • I SEE YOU …or the Power of True Sponsorship. Regular blogger, Claude Emond is also on the road and shares with us some of the lessons and observations from his travel “project” through Asia, and relates them to effective project management in business.
  • A First Pass at Defining the BA/PM Position Family. In this episode of the ongoing series that first appeared in Business Analyst Times, Bob Wysocki considers what skills and knowledge might be required in a role that combines both BA and PM responsibilities.

Also, don’t forget to check out our events calendar and some of the reactions other readers have posted in response to recent articles. And let us know what you think of this issue.

A First Pass at Defining the BA/PM Position Family

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,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.

Project Success Factors and Value Contracts

At some point in our careers we have innocently accepted a project with a poor or absent description of the project manager’s role and accountabilities. Usually this information is missing because the Project Management Office (PMO) executive failed to understand the full scope of the project and/or the project sponsor’s perceptions regarding the project manager’s role. The result involves the project manager wasting upfront critical project time defining their role and then selling their inclusion to the project sponsor and key stakeholders. This time is usually not replaced and puts an avoidable strain on the project.

The project charter briefly outlines the project manager’s role. Complementing and strengthening the project charter are two separate and distinct tools I use to clarify the project manager’s role, avoid misalignment and produce a harmonious project delivery experience.

The “Project Success Factors” and “Value Contracts” are tools that explain the specific deliverables, behaviors and actions that are expected from the project manager. Together they form an agreement that stipulates if such deliverables, behaviors and actions are produced by the project manager during the engagement the project sponsor and key stakeholders will irrevocably pronounce that the project was successful and that the project manager’s role in the initiative provided “value”. Think of these tools as assurance that the results of the project manager’s efforts will be truly recognized at the end of the project.

Project Success Factors

A project usually includes changes to operational logistics that may be perceived as a loss of control by some stakeholders. The result is personal agendas and stereotypes, organizational and interdepartmental politics, and conflicting cultures that mold misguided enterprise perceptions of the project scope. Naturally, a description of the in-scope work is included in the scope statement and charter. However, this description alone does not guarantee that, at the conclusion of the project, all stakeholders will agree that the project was successful. Most of the time, stakeholder defiance is due to changes (unknown, ignored or forgotten) that individual business units had to endure as part of the project and, at its conclusion, seek some retribution for these sacrifices. Thus, accompanying the project charter and scope statement is a detailed and holistic account of the exact deliverables that must be realized in order for the project to be classified as successful by the project sponsor and key stakeholders.

Begin by restating the project purpose, desired outcome and portfolio alignment. Then state the specific deliverables that must be produced for the project sponsor to classify this project as successful. You must be very specific; requests and actions that will not be delivered should also be listed. You may want to list easily delivered, in scope tasks that the project sponsor/key stakeholders have placed a heightened value on, but are not part of the critical path. These are considered “easy wins” and help build trust between the project sponsor/key stakeholders and manager.

Value Contracts

Recognition for the results produced by a project, as well as the accountability for the operational faults uncovered during the project, ignite competitive elements in most matrix organizations. Once these competitive forces are in full force, a project manager’s personal contributions may be “selectively remembered.” This lack of recollection eventually forms a common perception about the “value” added by the project manager. In most organizations perception is reality.

Selective perception is a psychological delusion that is dominant in most organizations. Limited time and the strength of interpersonal relationships will cause most senior managers to listen attentively to the gibberish provided by a trusted band of colleagues, fully versed in water cooler dogma, and ignore the lengthy details involved in the project charter they had previously signed.

A value contract is a brief outline (1 page) of the specific behaviors and characteristics that the project sponsor/key stakeholders wish to see the project manager display throughout the engagement. As well, it outlines the Key Performance Indicators to be used when evaluating the project manager’s contribution. Strong relationships, assertive and clear communications are also elements that will strengthen organizational perception regarding the project manager’s role and contribution. If the project manager’s value is contested a Value Contract will serve as a checklist for rebuttal.


George Konstantopoulos, PMP, PgMP, is a managing partner at Welch International Management Consultants Group. He has managed portfolios and executed program and projects in the telecommunications, banking, IT, marketing, utilities, retail and professional services industries. His entrepreneurial spirit and keen business insight have benefited many organizations through his effective consultative engagements and compelling achievements. George regularly lectures on project management and the PMP designation. Additionally, he facilitates quarterly seminars intended to prepare students to write the PMP designation exam. You may contact George at [email protected] or through his blog spot at http://welchconsulting.blogspot.com/

Keeping Project Scope Creep under Control

What issue consistently appears in the top ten causes of project failure, and what is the easiest and arguably most effective measure a Project Manager can take to virtually eliminate that issue?

The answers are “Scope Creep”, and “Change Management”, respectively.

Without a solid definition of scope, scope creep is almost inevitable, and implementing change management is like trying to swim up the Colorado River in full flood!! However, if the PM and their team do a good job of identifying and documenting scope requirements, then scope creep can be virtually eliminated by a good change management plan and unyielding execution.

So, assuming the project manager and team have started scope definition with a deliverables-based Work Breakdown Structure (WBS) and have then broken these deliverables down into activity definition, they will end up with a list of activities required to complete those deliverables. Great start! However, we all know that before the ink is dry on the scope definition, some kind soul will usually want to change it. Does this cause disruption to the project manager’s karma? Not if there is a good change management plan in place that has been communicated to all stakeholders and is being enthusiastically followed. Change is good and healthy for a project provided:

  • The entry point for change is the PM (without exception)
  • The change required has been well defined
  • All ripple or knock-on effects within and outside the project have been evaluated
  • All impacts on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis
  • The customer (or entity paying for the project) approves and authorizes the change

If any one of the above does not happen, your project is in serious jeopardy. Let us look at each element in turn.

The change request is given to the PM

Without exception, the change request’s path to glorious implementation starts with the PM who first receives it, logs it, then allocates it to a team member best suited to assess and evaluate that request.

It is well defined

A change is like any element of scope definition, if it is not well defined, neither the PM, the team, nor the customer can be clear or unified on what needs to be delivered, a grand opportunity for different interpretations by all concerned.

All ripple or knock-on effects have been evaluated

Once the change is received, the position of the affected deliverable on the WBS can be determined, and potential impacts on other areas can be assessed. Following this first assessment, a qualified team member can evaluate what other areas of the project may be affected. For example, lengthening an address line field from 25 to 35 characters on an input screen and database record may have impacts on many other areas such as invoice printing, search engines, etc.

All effects on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis

This is the crux of the impact analysis and is what the customer needs to understand before they authorize or reject the change. This may not only affect the baselines for scope, time, and/or cost, but other areas such as risk. The customer should also be able to assess the business case for the potential effects of implementing the change before authorizing.

The customer (or entity paying for the project) approves and authorizes the change

If the customer does not approve the change, the decision is logged and the change request filed with no further action by the PM or team. If the customer does approve the request, this formally recognizes that they accept all the implications and impacts of that change, particularly to the triple constraint baselines. This will be logged by the PM, who will provide authorization to the team to implement the change.

Summary

Once a change management process is defined and communicated, the next task is for the PM to review it thoroughly at the kick-off meeting so that the team is in no doubt of the process to follow if anyone asks them to implement a change, or if they want to propose a change themselves. It should be heavily stressed that no change at all will be implemented without approval by the PM. It is also advisable, for the PM’s longevity in the job, to emphasize that not adhering to this process would be a career limiting event!!

Why is this easy to implement? Because it just needs one standard process, communication of that process to all stakeholders, and strict adherence to the process during execution.

What if there is no impact to time or cost baselines, do we still need to go through the process? Absolutely yes! Suppose a minor screen change is requested that will re-arrange the appearance of fields on the screen and maybe add a new easily accessible field. None of this will take additional time or money to implement because it was requested before there has been any work done on that deliverable. But when it comes to acceptance, the acceptor will look at the specification, then look at what is delivered, and say, “This is not what I asked for!” and will fail acceptance because the specified deliverable and the actual deliverable are not identical. However, if there is a formally authorized change request to explain the difference, the acceptor will say, “Hey! This is awesome!” and will place a tick in the right box.

One common issue with this process is that the optimum resource to assess a change request is often working on a critical path activity, and time taken for evaluation may affect the timeline of the project. This has many project dependent solutions which could be the source of a further paper!

The moral is to identify, communicate, emphasize, and strictly adhere to a change management process – it could save the project, and with it, the PM’s career aspirations (but only where there has been a good initial scope definition).

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.

Copyright © Global Knowledge Training LLC. All rights reserved.

 


Bruce Beer, PMP, is a certified project manager with over 35 years in the IT industry and over 25 years of project management experience in Europe and North America . He established his own consultancy company (Apollo Project Management Consulting) and specializes in PM training, project recovery, and PM support. He is a project management instructor with Global Knowledge and is also a course developer. He works mainly in North America, but also in other countries, with extensive experience in Europe.