The Value of your PMP Qualification

January 29, 2010

Over the years there has been a lot of discussion on the value of credentials such as PMP; frequently triggered by the failure of a ‘qualified’ person to perform in the workplace.

There are essentially two ways to assess a person from a credentialing point of view. Testing what they know or assessing what they do. Competency based assessments (what they do) tend to assume knowledge based on performance. You cannot perform a complex task such as managing a project without knowledge. However, competency based assessments have two disadvantages:

  • Competency is demonstrated in a specific a time and location. There is no guarantee the competent person will perform as well in a different setting with different people, cultures and relationships.
  • The assessment of interpersonal competencies tends to be subjective and project management is very much focused on directing and leading people. Assessing behavioral competencies goes some way towards solving this dilemma but the assessment is still subjective.

Knowledge based assessments are empirical. The person had sufficient knowledge to pass a defined test at a defined point in time. However, the passing of a knowledge based assessment such as PMP or for that matter an MBA only shows the person has a predefined level of knowledge. The disadvantages of knowledge based assessments are:

  • There is no indication the person can apply the knowledge effectively in the workplace.
  • The knowledge tested in any exam is only a portion of the overall domain knowledge.

Given the problems with either assessment process, assessing the value of a qualification is complex and is differs depending on who is making the value judgment, an employer or an individual.

The value of a qualification to an individual can be measured in at least three areas:

  • The advantage it offers in the job market;
  • The recognition governments and other licensing authorities give to credential holders and
  • Its recognition by other entities offering higher qualifications through credits or advanced standing.

The value of a qualification to an employer is in part a function of the credentials reputation and in part, what this tells the employer about the credential holder. Whilst the PMP is a uniquely valuable industry based credential, no single assessment is ever going to provide a guarantee of a person’s suitability for employment in a particular organisation. Being a PMP provides one point of assessment; the PMP holder had the knowledge needed to pass a difficult, quality controlled exam. However, employers also need to look to other aspects of a person’s overall capabilities as well.

My feeling is the lack of undergraduate/baccalaureate degree courses in project management has given PMI’s PMP and other similar project management certifications a solid value in the job market. This is quite different to many other credentials issued by professional bodies. The UK based Chartered Institute of Building’s MCIOB credential requires a degree, several years experience, an examination and a professional interview; in most respects at least equal in its rigor to PMI’s PMP requirements. Both credentials should be assessed as being at a higher level than a degree but at least in the Asia Pacific region, the construction industry and governments focus on building managers holding a University construction degree, not MCIOB.

Similarly, higher degree courses in project management routinely offer some level of advanced standing for PMP holders. I am unaware of any advanced degree in construction or the built environment that offers similar advanced standing for MCIOB, although some other professional credentials do achieve a level of advanced standing in some higher degree courses.

This unusually valuable status of PMP as been built up over many years; however, the value also creates a number of challenges:

  • Employers may have expectations of PMP holders not supported by the credential.
  • But, credential holders need to live up to the reasonable expectations of their employers, and current credential holders also have the challenge of maintaining the worth of the credential for future generations of PMs.
  • PMI needs to ensure the examination process remains both credible and effective.
  • Training organizations such as ours need to ensure their PMP courses are relevant and interesting.

We have chosen to focus our training on the PMI range of credentials because they are a defined package, we know if we have done a good job as soon as a trainee passes their exam. The subjectivity of competence assessments lacks the clarity of pass/fail. However, look 5 to 10 years into the future and I expect the credentialing process will have change substantially to blend aspects of workplace assessment (competency) with the formal testing of knowledge. The Program Management Professional (PgMP) credential is a start along this route, my prediction is most other credentials will follow.

Advertisements

Understanding Stakeholders

January 24, 2010

I published a post on the PMI Voices on Project Management blog a couple of weeks ago; Is This Your Project Stakeholder?. The post outlined a scenario and provided two options for readers to respond to.

  • Option one was to focus on stakeholders and value with an enhanced probability of technical failure (running late and being over budget)
  • Option two was to focus on the ‘iron triangle’ of time cost and scope.

A surprisingly high number of comments from people in the IT industry chose ‘option two’ – just do the job, a focus on short term technical achievement. Whereas managers with a broader perspective tended to select option one for a range of reasons.

You will have to wait a few days for my second post outlining my views on the best answer and why (I have just finished writing it and its now being edited). So check the Voices blog ‘home page’ in a few days or follow my posts.

In the interim though I have to say I was amazed at the number of IT practitioners who still seem to believe IT is somehow disconnected from the overall business of the organisation. I would suggest 99% of IT projects involve changes to business processes and will never deliver their full value if the people working in the business don’t embrace the changes.

Further, I would suggest probably greater then 50% of all IT projects are specifically instigated to support a business initiative or change. Projects in this category are integral to the value creation process – if the IT project team alienate key stakeholders the whole initiative could easily fail to deliver value to the organisation and become a waste of time, effort and money.

I discussed stakeholders and change management a couple of weeks ago (see post)  and the ‘Value Chain’ was covered last year (see post)

Based on the responses to the PMI blog, there’s still a lot of work to do to convince IT practitioners that being on time and on budget are not directly related to value. Value is created when people (ie, stakeholders) actually use the IT implementation to generate wealth.


Managing Older Stakeholders

January 17, 2010

One of the impacts of the global financial crises has been for many people to defer their plans for retirement. From a physiological perspective this is quite achievable, people currently approaching their 60s were born after World War 2; their parents were children during the great depression of the 1930s and then went through the depravations of the war years. From a physical health perspective today’s 60 year olds are probably similar to their parents in their 50s. If this hypothesis holds true, the end of a baby boomer’s effective working life should be nearer to 75 than 65.

Diversity has long been recognised as contributing value to teams. Including older workers in a team contributes to diversity. Older workers have a lifetime of accumulated experience and provided they remain adaptable and ‘current’ can offer any project team a range of valuable capabilities ranging from wisdom and maturity through to teaching and mentoring.

There are interesting challenges though; the older person has to remain flexible and adaptive. The only best answer was not found 20 years ago and the tendency to become ‘set in ones ways’ is the biggest threat to the effectiveness of the older team member. Experience and lessons learned on past projects are valuable but need to be introduced to the team in subtle and sensitive ways.

Managing older workers also needs to take into account some of the immutable effects of ageing. Stamina and endurance levels reduce as people get older, the skeletal frame becomes more brittle and injuries take longer to heal. The solution is flexible working and if physical work is involved more careful job design. Whilst many older people find a ‘granny nap’ in the early afternoon helpful, after the nap they can keep on working until late at night (another effect of ageing is a reduced need for sleep). Similarly, many older people have learned disciplined work habits and will remain focused on a critical but uninteresting job far longer than youngsters, making fewer mistakes.

The biggest challenge is for young project managers faced with the prospect of managing someone nearly as old their parents. The young leader has to avoid becoming defensive and develop a productive working relationship using techniques similar to those used to ‘advise upwards’; assisted by the structural authority the project manager has over team members. Both sides of the relationship have to adapt but the advantages of applying good stakeholder management skills to make the relationship effective can have major benefits for the project, the project manager and the older worker.

Many skills are going to be in short supply as the recovery cuts in around the world and older workers represent a valuable pool of knowledge and talent. The demographic changes in most western societies are immutable; add in the effect of the GFC and those organisations and managers who learn to make effective use of the resource pool created by older workers wanting to stay in the workforce will have a significant advantage over those organisations that focus exclusively on competing for the diminishing pool of young workers.

What are your experiences in this area?


Stakeholders and Change Management

January 10, 2010

When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your project, program and your organisation.

Stakeholders and Change Management

Change Management and Stakeholder Management

Stakeholder management is a key facet of organisational management where stakeholder management is often aligned with marketing, branding and corporate social responsibility (CSR) initiatives.

Similarly, stakeholder management central to change management and the ability to realise the benefits the change was initiated to deliver. The benefits will not be realised unless the key stakeholder communities accept and embrace the changes.

Project and program management also has a focus on effective stakeholder management. In a change initiative, the project and/or program undertakes the work to deliver the elements needed to facilitate the change but are only ever part of the journey from concept to realised value.

A typical evolution of a change initiative would flow along these lines:

  • The organisation decides on a major organisational restructure and as a consequence initiates a change management process and appointed a change manager.
  • The change manager develops the business case for the program of work and the executives responsible for the organisations portfolio management approve the business case and agree to fund and resource the program.
  • The program manager sets up the program management team, established the program management office (PgMO) and charters a series of projects to develop the various deliverables needed to implement the change.
  • The projects deliver their outputs.
  • The program integrates the outputs with the operational aspects of the organisation.
  • The organisation’s management make effective use of the new systems and processes.
  • Value is created for the organisation and its owners.

The change manager is the sponsor and primary client for the program but the people who need to be convinced of the value of changing are the operational managers and their staff. If the organisation does not accept and use the new systems and processes very little value is generated.

Within this scenario, stakeholders in the operational part of the organisation, and particularly the managers will be key stakeholders for a range of different entities:

  • They are stakeholders in the organisation itself and part of the organisational hierarchy.
  • They are stakeholders in the change process being managed by the change manager.
  • As end users of the new systems and processes they are also stakeholders of the program.
  • As subject matter experts (SMEs) they are likely to be stakeholders in at least some of the projects.

In one respect change management is stakeholder management. Therefore, in a change management initiative, stakeholder management should be an integrated process coordinated at the change manager’s level. All of the organisational elements working on the change need to coordinate their stakeholder management efforts to support the overall outcome. Confusing and mixed messages don’t help anyone.

But this is just one typical business scenario. When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your organisation. Consequently, focusing on a simple one-to-one view is unlikely to provide the best outcome for anyone.

Effective stakeholder management requires a mature organisational approach. One approach to developing this capability is the SRMM (Stakeholder Relationship Management Maturity) model described in my book. Stakeholder Relationship Management: A Maturity Model for Organisational Implementation. I will outline the SRMM model in a later post.


Team Communication

January 4, 2010

Several of my recent posts have focused on the need for effective communication up the organisation to senior managers and clients. Successful project management also needs good downwards communication to and with the project team.

I have just finished reading two Executive Book Summaries from Soundview Executive Book Summaries . The first was ‘How did that happen’ by Roger Connors and Tom Smith, the second ‘The five dysfunctions of a team’ by Patrick Lencioni. Together these books emphasise the importance of effective communication within the team.

Lencioni suggests members of truly cohesive teams; trust one another, engage in open discussion of ideas, commit to decisions and plans of action, hold one another accountable for delivering against those plans and focus on achieving effective results. Trust and respect are the elements needed to allow this to happen.

From the perspective of project delivery, the key elements are active discussions leading to decisions that are represented by the project plan and then focusing on achieving the plan. The agreed plan represents the expectations of the project manager and the team for the performance of the work. But how to turn these expectations into reality?

Connors and Smith show how the project manager can hold the team responsible for results in a positive, principled way. The first step is for the PM to test the expectations contained in the plan to ensure each one is consistent with the overall plan, achievable by the currently available resources, and that the ultimate fulfilment of the expectation is measureable. An expectation may be a document, a piece of code, a successful test or any of the other elements needed to deliver the project to meet the expectations of the client.

Communicating specific expectations to the team members responsible for the work uses a why, what, when approach. The ‘why’ needs to be compelling on a personal level to the individuals concerned; this is helped if they are already committed to team achievements. The ‘what’ requires clarity; not just about the deliverable but also the boundaries of the work and the available support. Lastly, the ‘when’ needs to be precisely defined. The schedule, WBS, and other project documents usually contain the needed ‘what and when’ information, the challenge is using these documents as effective communication tools to build commitment and motivation in the team.

To maintain accountability, it is vital the PM routinely inspects what is expected. Making sure the ongoing work is aligned with the original expectations and any changes are properly managed. Holding people accountable needs the PM to precisely understand things as they really are and to be able to identify and diagnose any problems. Accountability is not ‘blame’ it is a joint process to commit to the truth and then act to develop solutions, overcome obstacles and deliver results.

Accountability is the key! Team members hold themselves and their colleagues accountable and work together to achieve results that meet the expectations of the PM and the project’s clients. To achieve accountability, open and effective communication between everyone in the team is critical and the PM has to be the ‘first among equals’ leading the process. This is one of the reasons a PM should spend 90% of her time communicating.

More next time.