Tag: PRINCE2

Project Management: How has it Changed after the Recent Global Financial Crises?

Written by Mike Morton on September 26, 2012. Posted in Articles. 11 Comments on Project Management: How has it Changed after the Recent Global Financial Crises?

FEATURESept26th Changes in professions arise from a culmination of many factors, including advances in technology, responses to changing markets and the wider economic environment, alterations in demographic trends, and customer-driven demand, to name just a few. As well as industry-driven advancements, major shifts in the global economy and global events can have a profound, structural effect on a multitude of professions. Major global changes bring about a realization that “We cannot continue to do what we have always done.”

The full impact of the global financial crisis that began in 2008 on all aspects of the economy may take years, or even decades to fully understand. It is arguably true that the crisis has “left its mark” on attitudes towards the project management profession (as it has on many other professions). Some changes have been challenging at an individual level, such as the struggle for many to maintain gainful employment. Other changes have spurred positive adjustments to the way the profession operates, such as fostering a drive for advanced project management processes and a general realization of the importance of project management to controlling outcomes with scarce resources. In this article, we review what some of the post 2008 changes on the project management profession have been.

The post 2008 global economic downturn has been a catalyst for organizations to rethink their processes. The approach to project management (plus program and portfolio management) has, for many organizations, been part of this overall rethink. In many cases, the outcome has led to project management being recognized as a valuable way to provide surety and control of initiatives undertaken. This has led to opportunities and also some challenges for those of us in the profession.

We categorize the key impacts on project management brought about by the financial crisis into three areas: Changes to the Profession, Changes to Methodology, and Changes to the Professional.

Some key changes to the Profession

The need to control risk and provide a greater certainty and control of project outcomes has led to an increase in the awareness of project (and for that matter, program and portfolio) risk management. The benefits of effective project risk management are well- documented. Organizations that were previously unfamiliar with project risk practices, or had immature processes in place, have started to explore the benefits of implementing a thorough and rigorous approach to project risk management.
A related effect is a greater emphasis on portfolio planning of projects (for whatever industry the organisation is in – construction, oil and gas, pharmaceutical, NGO, IT, etc.). This has created a positive opportunity for those professionals skilled in portfolio management practices.
There is an increased interest in credentials and certifications to complement experience. Competition for jobs is fierce, and experience remains as vital as ever. Many professionals are adding credentials and/or certifications to their resume to make themselves more appealing in a tight job market, and in response to more and more job advertisements asking for a minimum of credentials from interested applicants. This change is having several effects on the profession. As more professionals seek credentials and certifications, project management has become a career option open to more people. The ripple effect is providing a positive impact on the wider economy, with the “economic multiplier effect” of more employment in training, preparation and exam administration to support this up-skilling need. Several government and not-for-profit organizations offer financial assistance for job training, which provides underemployed/unemployed with educational opportunities, while further extending the benefits to the training providers.

Some changes to the Methodology of project management

There is a greater emphasis on ensuring that projects have genuine “governance with teeth”, and Limits of Authority are being more tightly controlled for authorising expenditure, budgets, scope changes, etc. Savvy Project Managers need to leverage this because it is good for their control of projects, and, in order to do so, they must understand how to make governance effective. They must prepare governance properly and ensure it is run like clockwork.
The approach to risk management (mentioned above) has become more sophisticated, particularly for large projects. Project Managers need to capitalise on this and ensure they know how to practice risk management in a way that involves all project stakeholders (it is not just about having a better risk register, it’s about pro-actively managing risk).
Thresholds for change controls and performance metrics are tighter. Competent project professionals are striving; those at the lower end of the talent pool will find it a challenging environment in which to operate.
Resources for projects are expected to do more with less, so the project manager is expected to better manage those resources to achieve success. In such tight environments, the project manager’s skills in leadership are more important than ever and the methodology chosen has a major impact on how resources are managed.

Some changes to and impacts on the Professional

Many people are taking jobs at levels of pay that are lower than before 2008 because of what the market and employers are currently offering. With double digit unemployment prevalent in many countries, it has become a “Buyers’ Market”, leading to lower salary costs to organizations. Many professionals who are qualified for senior level roles are taking lesser roles. Underemployment, while not optimal to the professional, can yield benefits to those employers that acquire and leverage top talent.
It is probably true that today, more contract and temporary positions in project management exist in proportion to full-time positions. Professionals that once had traditional, full-time, stable roles may be forced into contracting, which can be less secure. However, this can also provide many people the opportunity to broaden their experience and build a stronger resume, as well as gain more autonomy in their work-life balance.
People in career transition between gainful employment probably carry out more volunteer roles as it helps to fill the employment gap in their resume.
Social networking is growing in importance for career management – look at the increase of LinkedIn and Facebook membership.
Faced with career challenges, some PMs are changing careers and exiting project management to do something else.

In conclusion, this article touches on a few salient points of how the global economic crisis of 2008 has led to changes in the project management profession. As has been the case for many other professions, the crisis has led to many shifts, some positive and some negative. The lessons we learn from the economic downturn can help prepare us individually as well as organizationally for the next major shifts that occur.

It is important for us all to be prepared for continued change. Louis Pasteur once said that “chance favors the prepared mind.” H.G. Wells is quoted as saying: “Adapt or perish, now as ever, is nature’s inexorable imperative.” We must prepare ourselves for continued change by constantly honing our processes, developing professionally, and being willing to adapt. Those individuals and organizations that are prepared and that embrace the opportunities presented are the ones that are set to continually strengthen their position.

Don’t forget to leave your comments below.

Gareth Byatt has 15+ years of experience in project, program and PMO management in IT and construction for Lend Lease. Gareth has worked in several countries and lives in Sydney, Australia. He can be contacted through LinkedIn. Gareth holds numerous degrees, certifications, and credentials in program and project management as follows: an MBA from one of the world’s leading education establishments, a 1st-class undergraduate management degree, and the PMP®, PgMP®, PMI-RMP®, PMI-SP® & PRINCE2 professional certifications. Gareth is currently a Director of the PMI Sydney Chapter, he is the APAC Region Director for the PMI’s PMO Community of Practice and he chairs several peer networking groups. He has presented on PMOs, portfolio and program and project management at international conferences in the UK, Australia, & Asia including PMI APAC in 2010.

Gary Hamilton has 16+ years of project and program management experience in IT, finance, and human resources and volunteers as the VP of Professional Development for the PMI East Tennessee chapter. Gary is a 2009 & 2010 Presidents’ Volunteer Award recipient for his charitable work with local fire services and professional groups. He has won several internal awards for results achieved from projects and programs he managed as well as being named one of the Business Journal’s Top 40 Professionals in 2007. Gary was the first person globally to obtain the five credentials PgMP®, PMP®, PMI-RMP®, PMI-SP® , CAPM® . In addition to these, Gary holds numerous other degrees and certifications in IT, management, and project management and they include: an advanced MBA degree in finance, Project+, PRINCE2, MSP, ITIL-F, MCTS (Sharepoint), MCITP (Project), and Six Sigma GB professional certifications.

Jeff Hodgkinson is a 32 year veteran of Intel Corporation, where he continues on a progressive career as a program/project manager. Jeff is an IT@Intel Expert and blogs on Intel’s Community for IT Professionals for Program/Project Management subjects and interests. He is also the Intel IT PMO PMI Credential Mentor supporting colleagues in pursuit of a new credential. Jeff received the 2010 PMI (Project Management Institute) Distinguished Contribution Award for his support of the Project Management profession from the Project Management Institute. Jeff was the 2nd place finalist for the 2011 Kerzner Award and was also the 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award TM. He lives in Mesa, Arizona, USA and is a member of Phoenix PMI Chapter. Because of his contributions to helping people achieve their goals, he is the third (3rd) most recommended person on LinkedIn with 570+ recommendations, and is ranked 55th most networked LinkedIn person. He gladly accepts all connection invite requests from PM practitioners at: www.linkedin.com/in/jeffhodgkinson. Jeff holds numerous certifications and credentials in program and project management, which are as follows: CAPM®, CCS, CDT, CPC™, CIPM™, CPPM–Level 10, CDRP, CSM™, CSQE, GPM™, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMI-SP®, PMW, and SSGB. Jeff is an expert at program and project management principles and best practices. He enjoys sharing his experiences with audiences around the globe as a keynote speaker at various PM events.

Is Accountability a Key Component for Project Management?

Written by Lisa Anderson on August 22, 2012. Posted in Articles. 9 Comments on Is Accountability a Key Component for Project Management?

FEATUREAug22nd Is accountability a key component to project management? Only if you want to succeed! I often make the mistake of assuming that project leaders and team members understand the critical value of accountability (as I believe it is bedrock to success); however, it isn’t necessarily true. Recently I received feedback about the importance of accountability and the focus on results, and so I thought it prudent to focus on the why and how of accountability.

Without accountability, there’s no reason to lead a project or be on a project team as you’re doomed for failure. Yet this isn’t nearly as easy to achieve as it might seem. Often, the members of a project team report to a different organizational leader, and so direct authority can be non-existent. Also, often, project tasks are considered 2^nd priority to day-to-day responsibilities. Thus, how do we ensure accountability for project management? A few keys to success include: 1) Set expectations. 2) Track progress. 3) Integrate with performance management processes.

Set expectations: In my 20+ years of experience across multiple industries, I’ve found it is easy to assume that project expectations and goals are clear when they are vague at best. How can they be vague when you have a written document with tasks and accountabilities? Just ask yourself a few questions: 1) If a mini-crisis arises (such as a potential late shipment or a machine issue), will your project lose focus? 2) If a team member’s direct manager needs a report or action item completed, will your project lose focus? 3) If your project comes into conflict with department priorities, will your project lose focus?

Most times, I see these issues derail projects. It’s the rare exception where a project manager and executive sponsor think through the potential conflicts, determine priorities and communicate clearly upfront. In these cases, not only is the projects successful but typically the other needs are addressed as well. Think about the 80/20 – which of these types of situations are most likely to occur? How will you handle them? Bring the team and all related parties into the loop as to the priorities, reasoning and process for resolving issues. Miraculously, your project will exceed expectations.
Track progress: Tracking project progress sounds like motherhood and apple pie; however, what could be more integral to success? If you don’t know how you are doing, how will you know what to adjust?

How do we accomplish this? It is not sufficient to wait to track progress until the project results timeframe. Instead, track the progress of milestones especially critical path milestones. The 80/20 of your effort should be on these key milestones as they will drive success. If you aren’t sure how to track progress without the end result, ask questions. Find out how core team members or project recipients would “see” progress. If critical path milestones are too far out, find out which tasks along the path to the critical path milestone are most likely to run into a roadblock. Be all over it!

Don’t just track task timing. Review the level of quality / result of the task. Review costs. Review service levels. Ask for feedback. Ask your customers.
Integrate with performance management processes: People focus on what’s measured. Does their performance on your project make a difference to their career success? How can you ensure integration with the performance management process?

There are several approaches to achieving this objective: 1) Publish and communicate metrics on a frequent basis – preferably weekly. 2) Partner with the organizational leaders associated with your project team members. Make sure the project objectives are a part of each team member’s regular performance management process. 3) Make sure the priority of your project is clearly understood in relation to other projects and day-to-day responsibilities. If this means your project is 2^nd priority, address upfront. What backups exist? How else can you fill gaps? 4) Clearly communicate the value to the project team members and the rest of the organization. 5) Provide continual feedback (both positive and constructive) and back up with rewards, recognition and performance discussions.

Without a doubt, those companies who consistently deliver project results will outperform their competition. Accountability plays a vital role in ensuring success. Will you put forth the effort to institute accountability practices in your project?

Don’t forget to leave your comments below.

Realizing Benefits – It’s What Projects Are For!

Written by Gareth Byatt on May 16, 2012. Posted in Articles. 13 Comments on Realizing Benefits – It’s What Projects Are For!

Co-authored by Jeff Hodgkinson

Realizingbenefits4_main We believe a simple methodology can be applied to attain Benefits Realization. You can achieve true project success by ensuring that:

Project benefits are clear, concise and relevant in ‘value creation’ terms from the Business Case onwards, and that they directly relate to your organisational strategy
People are held accountable for achieving these benefits
Benefits stated in a Business Case are actively measured throughout the entire initiative, ie:
- During the project lifecycle (particularly if it is released in phases)
- After the project is closed
- When the product/output starts to be used
Appropriate action is taken if required to alter direction (i.e. the organization changes course and the intended project benefits are no longer relevant)

Simple Process Flow for Project Benefits Realization

Realizingbenefits1

It Starts with a Good Business Case!

In the project management community, it is generally accepted that a project starts in earnest once a business case has been agreed to and various other initiation tasks are complete. The question now is, “Does your business case remain a core reference document throughout the project’s lifecycle?” or does it go into the project files, to be reviewed only if, say, key stakeholders request a change order or when project auditors visit?

Business cases vary in size and complexity. A business case, and the process to agree to it, should include the following elements relating to benefits realization:

Clearly show how the initiative contributes to the organizational strategy including the core reason for the initiative. There must be measurable benefits that specifically relate to the organization’s goals and objectives
People must be named as accountable for ensuring the benefits are achieved (and they must know and accept this accountability)
People must agree to these benefits being monitored over time, with appropriate adjustments made when necessary

Our Three Main Points

1. Contributing to the Organizational Strategy

Circulate your proposed business case benefits with all key stakeholders to ensure they “stack up”, and a ‘governance’ control group should oversee and approve key project decisions regarding agreed benefits, including business case approval. Remember, it can be all too easy to inadvertently omit certain stakeholders from the loop. From the beginning, ensure benefits monitoring is built into your project – it will keep you on track to deliver what your cstomer needs. It is most useful to include the strategy for tracking benefits in the business case. This can be high-level or it can be a detailed explanation, depending on the circumstances. One word of warning: benefits tracking can mean many things, and can be subject to lack of clarity without the right level of rigor being applied. The sample extract from a business case below shows benefits, accountabilities, metrics (if applicable) and the proposed timeframe for realization:

Realizingbenefits2

When assessing benefits, and following through in the post-delivery phase, one should talk to people across the organization vs. taking one person’s opinion as the complete story. Ensure that the focus is on creating value, and that it is realistic. For example, drawing up “use cases” of real-life scenarios of how people will perform activities with the new deliverables in place can help to define the realistic benefits. This is what may be termed “active planning” for change, rather than “passive planning” as it means you will understand the true value creation process. It can help ratify the scope and intentions of your project, which should mean the people nominated as accountable for achieving the benefits are confident of their delivery (and hence they should be comfortable in signing up to them).

A business case may not always state specific financial benefits. Projects can be charted to contribute to a strategic objective of an organization where:

Clear-cut financial returns are not directly evident.
Are Implemented as control measures in response to statutory requirements or legislation.

It is wise to include financial metrics in a Business Case only if they can be substantiated; financial justifications should not be included if you cannot justify and measure them (but track financial improvement in future if possible).

2. Assign Accountable People for the Benefits in your Business Case

The governance group you establish for your project plays an important part in ensuring benefits are measured once the project is closed and the operations or sustaining teams start to use the deliverable.

Assigning key people as accountable for realizing stated benefits should give a business case the importance it needs to ensure those benefits are traceable. The key to success is to make sure the benefits are realistic and measurable.

To link business case benefits with ongoing benefits realisation, we have found it useful to clearly state in the business case that a benefits realisation plan will be implemented to track the proposed benefits over the initiative’s total lifecycle. We have found it can be helpful to include the proposed benefits realisation plan tracking mechanism as an addendum to the business case.

One example format (many exist) is shown below:

View Larger

3. Monitor Project Benefits Over Time

Successful project delivery is an important first step to achieving business benefits – completing a project on time, budget and to expected quality levels sets the platform for ongoing success. However, what we are most concerned about in benefits realization is to ensure the deliverable that the project provides generates benefits as intended (or perhaps new, unforeseen ones) over its lifecycle.

Sometimes project deliverables need to be adjusted before the project is complete or at a point in time after project closure. For example, as circumstances change, unexpected external impacts arise, or new opportunities result in a change of organisational strategy. This is often true for long duration projects. Such changes need to be fed into the benefits realisation plan, so that it is kept up to date and is ready to be used as soon as the project closes.

We have found that benefits realisation plans can be structured in “layers” – that is, specific project benefits can be measured regularly and aggregated at a program and/or portfolio level for overall benefits assessment and tracking.

Our Conclusions

The realisation of project benefits can be considered to be dependent on the following five principle factors:

Business case benefits should to be clear and concise, and relate to the organisational strategy
Give your business case importance by assigning the people who will be accountable for achieving stated benefits in your business case (after obtaining authority to do so). Make sure the business case signatories agree and understand that benefits will be tracked and corrective actions will be taken in the event of a change or direction, or failure to realise the stated benefits
The benefits stated in a business case should be actively measured through continuous participative engagement after project closure in a benefits realization plan
Action should be taken if a benefit is not being realised (for example, if the organisation changes course or the project deliverables are no longer relevant)
Lastly, giving people a continued focus on benefits throughout a project helps keep it on track, and for the “big picture” to be maintained. It is from this vantage point that we can ensure projects deliver the benefits they were intended for.

Summary Extract

Today, more than ever, project benefits need to be achievable, then realized and then sustained (maintaining relevance) when your project is complete and its output goes into use. Adopting a simple ‘project benefits realization tracking method’ starting from the project’s business case onwards can help you achieve this…

Mini Glossary:

Terms Used	Brief Description
Benefits Realization	What the project intends to deliver to the customer/stakeholder upon completion.
Business Case	Why the project is being done and what justifies the resources being used.
Project Lifecycle	The phases a project goes through between start to finish. Typically 3 to 5.
Project Benefits	What will be the long term results or gain derived after completion of the project.
Governance	Management group that approves the project charter and subsequent phases if needed.
Strategic Objective	High level business objective which the project has inclusion to achieving it.
Deliverable	A result gained either during or at the completion of a project.

Don’t forget to leave your comments below

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation He’s a PgMP and PRINCE2 practitioner, and holds an MBA and first-class undergraduate management degree. Gareth has worked in several countries, and is currently located in Sydney, Australia. Gareth has 13 years of project and program management experience in IT and construction. Gareth can be contacted through LinkedIn.

Jeff Hodgkinson is the IT Hosting Transformation Program Manager. He is a 29-year veteran of Intel Corporation with a progressive career as a Program/Project Manager. Jeff holds numerous certifications and credentials in project and program management including PMI’s PgMP (Program Management Professional) credential. He obtained his PMP (#713) in 1991. He is located in Chandler, Arizona, and also volunteers in various support positions for the Phoenix PMI Chapter. Due to simply helping people, ‘Hodge’ as referred to by his many friends is one of the most well networked and recommended persons on LinkedIn.

Gareth and Jeff met through LinkedIn and share a common passion for program and project management theory and practices. Though they live half a world away from each other collaborate and co-author articles. Together they bring over 40 years of experience into their subject writing for the benefit of their colleagues worldwide.

Project Success Plans – Planning for Success

Written by Gareth Byatt on May 16, 2012. Posted in Articles. 13 Comments on Project Success Plans – Planning for Success

Co-authored by Jeff Hodgkinson and Gary Hamilton

“A Project Success Plan can be a platform for ensuring all project stakeholders start off, and continue on, the right footing.”

Setting up projects to succeed in the view of the customer/stakeholder is a critical part of the Project Manager’s role. We suggest that, as part of project planning activities in the early stages of your project, you should hold a Project Success Plan (PSP) meeting with all key team members to agree on the project’s goals, and to discuss the emotional success factors that will ensure the team gels successfully to deliver the required outcomes.

A Project Success Plan (PSP) is different from a Project Management Plan (PMP), sometimes referred to as a Project Execution Plan (or PEP). A PMP is a typically produced by the Project Manager to describe how the project will be managed and controlled in its delivery/execution phase, whereas the PSP is a documented meeting convened by the Project Manager to discuss and agree “what success means” to all key stakeholders. The PSP (like a PMP/PEP) should draw from project artefacts such as the Project Charter and the Customer Brief.

Project Success Plans can Help the Team to “Gel”

Have you ever managed or been involved in a project where, at one point or another, you felt that you were not on the “same page” as other team members? Ensuring everyone on a project team is continually pulling in the same direction can be a challenge. A Project Success Plan can help you to set a solid foundation for stakeholder interactions throughout the project, and to ensure you can detect and rectify any occurrences where stakeholder views and actions start to deviate off plan. In order to ensure everyone starts off on the right foot, it is important to kick off your project communications strategy properly. By this we mean, ensuring that everyone’s interpretation of success and their assumptions about the project are aired and discussed in an open group forum, which can be documented and evaluated in a Pareto-type chart format to indicate importance. This is the essence of the Project Success Plan.

The Project Success Plan is a communications planning tool in the project manager’s toolkit to get all key project stakeholders on the same page, and understanding each other’s prerogatives and drivers for success. This is not always an easy task, since there are likely to be a range of drivers and interpretations of project success amongst your stakeholders. For example, team members who are recipients of the end solution/product may have very different views and expectations of what project success means to those who are focused on delivering the product. It is also likely that some (or maybe all) team members in your project will be working together to achieve a specific objective for the first time. Indeed, the number of stakeholders who have worked together on projects before is an interesting statistic for the project manager to take note of at a project’s start. A Project Success Plan meeting should aim to achieve the following outcomes:

serve as an ice breaker for team members to get to know a little about each other
discuss and agree the basis for setting the criteria for achieving success;
team members agree and commit to their roles and responsibilities for the project;
everyone should understand each other’s personality and modus operandi;
everyone’s assumptions about the project and their drivers should be aired, discussed and documented;
a win/win philosophy and a collaborative approach throughout the project needs to be fostered,
the team should discuss their collective lessons learned from previous projects/experiences.

The points above are all about communication and common understanding. By understanding how to handle your key/extended teams’ communications with each other, stakeholders can avoid accidental and sometimes costly mistakes in communicating information and decisions during the project’s life. For example, ensuring that people discuss how meetings, reports and controls should be conducted will help set reporting expectations (e.g. if one person thinks project status reports are “a waste of time”, find out why and talk it through).

Because of the emotional focus of a Project Success Plan meeting, it should be held face-to-face whenever possible, however this may not be possible for smaller projects – particularly those that involve geographically disperse stakeholders. In such situations, a virtual conference meeting may be the most practical option. This requires special emphasis from the Project Manager in facilitating the meeting to validate everyone’s opinions frequently, ensure good feedback, and level set expectations for the project, since the important signs of body language will be missing.

The Timing of a Project Success Plan.

A Project Success Plan should be completed early in the project’s life, as soon as all key members of the project team are in place. Key members are those with a material interest and/or delivery focus in the project. The timing for holding a Project Success Plan meeting can typically be after initial set-up works are complete and the project reaches the start of its detailed planning phase. If stakeholders change during the course of the project, the project manager should include reviewing and updating the PSP with the new stakeholders as part of the Resource Planning.

A Project Success Plan can also be a tool the project manager uses to keep the team focused and engaged. When stakeholders are suffering from project fatigue, the project manager can refer back to the Project Success Plan and use it to motivate the team by reviewing the reasons for the project and what success means to each person.

How should a Project Success Plan be structured; Do All Projects Need One?

All projects will benefit from a Project Success Plan meeting, because it is a mechanism to ensure the following aspects are agreed to:

Do we all agree on the core reasons for the project’s existence?
Are we all on the same page? Can we agree how to work together (including our roles and responsibilities, team meetings and communication protocols, team member working styles, governance processes and expectations)?
Are our assumptions about the technical aspects of the project (such as the design, scope, build methodology, work breakdown structure, schedule, budget and method of managing change) clear?

Large, complex projects have many different stakeholders, often spread across many geographic locations. A Project Success Plan for a large project may benefit from being led by a skilled facilitator, and it may need to last several days. Small projects with less complexity will typically not require the same level of detail.

The structure of a Project Success Plan meeting should ensure the emotional success factors are fully aired. It needs to bear relevance to the core Deliverables of the project regarding scope, budget, schedule and quality. An example of a Project Success Plan meeting agenda is shown below (the nature of your project’s Project Success Plan agenda will be tailored to the project):

Agenda Item

1. Project Introductions and Executive Summary

2. What is the definition of “project success”?

3. Our Project Methodology

4. Project Fundamentals, Principles & Key Drivers

5. Project Assumptions by us all, and how we all work

6. Project Scope, WBS, Schedule, Quality and Budget

7. Project meeting, governance and review strategy

8. Project Organisation and Role Definitions

9. Communications Management strategy

10. Tracking Benefits after Go Live

Conclusions

A Project Success Plan is a mechanism to achieve the following positive outcomes for your project:

Ensure all assumptions about the project, and the meaning of success, are aired and discussed, and any misunderstandings and/or disagreements are resolved early in the project’s lifecycle.
Ensure project team members get to know how to work with each other so that communications throughout the project are efficient and productive
Assist the project manager in keeping the team focused and engaged, especially on projects of long durations.

Done well, a Project Success Plan meeting can help project managers and the entire team understand how to work together successfully, communicate well with each other, and be a tool to keep the team focused and engaged for the duration of the project.

Planning for success increases your likelihood of a successful project outcome. It is always important to ensure the “facts” of project scope, schedule, design, quality and budget are given due consideration. It is equally important to ensure the emotional aspects of project teamwork – team member expectations, their way of working, their personal aspirations for the project and their assumptions on how the project will unfold – are managed. A Project Success Plan is a method to bring out these emotional aspects. It can be a good platform to ensure the whole team continually pulls in the same direction to make your project a success.

Don’t forget to leave your comments below

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation. He’s a PgMP® and PRINCE2 practitioner, and holds an MBA and first-class undergraduate management degree. Gareth has 13 years of project and program management experience in IT and construction. He can be contacted through LinkedIn.

Jeff Hodgkinson is the IT Cloud Program Manager for Intel Corporation. He is a 30-year veteran of Intel with a progressive career as a Program/Project Manager. Jeff’s credentials include PMI’s PgMP® and PMI-RMP® (Risk Management Professional) Jeff was 2^nd place finalist for the 2009 Kerzner International Project Manager of the Year Award. He can be reached through LinkedIn.

Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary has 14 years of project and program management experience in IT, Finance and HR. He holds an advanced MBA degree in Finance and several certifications and credentials program management including PMI’s PgMP® (and PMP®.. Gary can be contacted through LinkedIn.

Project Manager and Business Analyst In Tandem for Success

Written by Sergey Korban on February 29, 2012. Posted in Articles. 13 Comments on Project Manager and Business Analyst In Tandem for Success

I’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence, just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.

I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.

How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them: a project manager and a business analyst are the two sides of the same coin. Their skills and joined efforts make a project successful and deliver good value to the business. I would like to demonstrate how a PM and a BA could work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project lifecycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a Project Initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.

PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and definition of the business need, expected project outcome (deliverables) and project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and Requirements Management plan with the PM.

Once the plans are agreed, the BA works closely with the project stakeholders on clarifying the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, as well as tolerances to a solution. The BA determines solution scope, high level requirements, solution approach, reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: Project Vision and Solution Vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, defines what is in and what is out of solution scope.

These two documents support the Business Case document in medium and large projects, supporting project sponsor’s decision-making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure that the solution can be assembled in a way that enables cost efficiency and adherence to project time and resource constraints.

Project Execution

This phase flags even more close collaboration between PM and BA. They work together in requirements workshops to prioritise and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communication with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here. The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

Having the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates the project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the Lessons Learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing over the years how different PMs tackle their projects, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude to a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders – all these elements create a foundation for blame for not delivering on time and under budget.

Conclusion

The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with collaborative attitude pave a way to project success.

Don’t forget to leave your comments below.

Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog