Author: Gareth Byatt

A Holistic Look at Program and Project Constraints

Written by Gareth Byatt on September 1, 2010. Posted in Articles. 3 Comments on A Holistic Look at Program and Project Constraints

The Triple Constraint of managing the interaction of time, cost and scope is a familiar model to most Program and Project Managers.

Delivering projects on time, within budget and per an agreed scope can be considered to be a “good result” by the project team. But effectively managing these constraints does not guarantee that the project is deemed a success by all of its stakeholders. Additional project constraints need to be taken into account to determine whether “complete” project success is achieved.

A general starting point for these additional constraints is this: think about the longevity of the project’s end output. Take a moment to think about projects you have been involved in, or known about, that finished 12 months ago or longer. Did they deliver their end output on or before schedule, on or below budget and did they fully meet the requisite expected level of scope and quality? If so, great. Now fast-forward to today. Do you know how well the end output of that project is being used? And does it contribute to the organisation in the way that may or may not have been originally anticipated?

History has many examples of projects that had a rocky ride until their completion, only to see the end outcome be fantastically successful over a period of time. For example, consider the Sydney Opera House. The design was very challenging to build, and for various reasons the project was completed well over time and budget. Not a great start to its life. Today, this iconic building is one of the most visited landmarks in the world and is considered an icon of Sydney, and Australia. In retrospect, if you queried the project’s stakeholders today, arguably all would agree that regardless of the time and budget overrun, the project has been a great success.

Our take-away messages from this article are as follows:

A project’s success depends on how well positioned its end output is placed to enable long-term benefits to be derived, and how successfully these benefits are then achieved over the lifespan of its use
If your project is part of a portfolio and/or program of works, its success needs to be measured by how well it contributes towards the portfolio and/or program as well as how successfully it is delivered in its own right

Please note that our article does not seek to supplant the Triple Constraint as a principle. Instead we put forward some suggestions on additional constraints that impact project success.

Here are our main pointers for consideration:

A project’s budget, schedule and scope need to be aligned to the overall benefits of the intended output using benefits management
Customer and stakeholder satisfaction should be measured with a view to delivering the agreed benefits during the project and the operation of its end output
Integrating the project into the organisation it is being delivered for depends on successful implementation planning (if your organisation has a Project Management Office, its level of maturity will impact this)
Managing risks (positive and negative) throughout the project should “focus people’s minds”
Team dynamics, the organizational structure in which the project exists within and the methodology used to implement the project are important constraints that impact project success

Our “double tetrahedron” below describes the main elements to these constraints:

AHolisticLookatProgram1

Let’s look at each main point in turn:

A project’s budget, schedule and scope need to be aligned to the overall benefits of the intended output using benefits management
To manage a project to budget, schedule and scope is of course important; nobody will dispute that. But take a moment to consider how focusing entirely on these three constraints during design and build (or implementation) can potentially create a “blinkered affect”, which could have a detrimental affect on the long-term use of a project’s output and the benefits it is intended to provide. What if, mid-way through implementing an agreed element of design, your team is faced with a choice on “which way to build to scope”? Choosing Option A is easier for them, and it allows you to keep on schedule and budget; choosing Option B will throw you off course, be a hassle to an already busy team, but – and here’s the but – if you think hard about it, you know it is the best option for the end users of your final product. In such situations it is worth pausing for a moment, consulting key stakeholders and making the best choice for the longevity of the product – be it Option A or B. Think hard about the end benefits your project is designed to provide. As long as you have good project management processes in place you will be able to manage any scope, budget and/or schedule change through change control procedures.
Customer and stakeholder satisfaction should be measured with a view to delivering the agreed benefits during the project and the operation of its end output
This statement stands to reason, but it is not always easy to achieve – it needs focus early. The devil is in the detail. Reaching agreement on the right measures (be they Key Performance Indicators, KPIs, or “Satisfaction Measures”) to track, during a project, and once its output is in use, should be a key part of your project planning. The measures you agree are project constraints. Large projects with many internal and external stakeholders will inevitably have many needs, and as a result it may not be practical to report all KPIs to all stakeholders – some KPIs will be relevant to a particular group, others will not be. The type of industry you are working in has a large bearing on the measures used as well. Consider whether customer and stakeholder satisfaction is dependent on “external constraints” of other projects within a program or a portfolio. If it is, understand what these constraints are and how your project influences, and is influenced by them.
Integrating the project into the organisation it is being delivered for depends on successful implementation planning
In our parlance, “Implementation Planning” is about setting up the organisation structure so that when the project’s end output is ready for use (be it a new car design, an IT system, a new hospital), the organisation can maximise its adoption. For example, making sure that customer support networks are in place, and/or that ongoing product management will ensure the new product/output is continually improved and maintained. Your project may well be part of a Business Plan that requires several projects to be integrated to achieve maximum value. Thus, understanding these dependencies (or constraints) is vital to its success.
Whilst Implementation Planning may not seem like a direct constraint to a project whilst it being built (or configured), it is – because if you do not give it adequate focus during your project’s delivery phase, your customers and other stakeholders may not have the right level of urgency and desire to ensure the project’s efforts are geared towards the best long-term outcomes for their organization(s).
Managing risks (positive and negative) throughout the project should “focus people’s minds”
Effective project risk management is generally recognised as a key determinant of project success. Risk management is more than maintaining a Risk Register; it is about ensuring that all opportunities and threats are being constantly monitored, with effective strategies to deal with them being agreed and implemented.
Risk management is a key constraint to delivering a project and the way you manage risks. The appetite for risk that your key stakeholders have, is an important determinant of success.
Team dynamics, the organizational structure in which the project exists within and the methodology used to implement the project are important constraints that impact project success
Let’s consider each of these three “perimeter constraints” in turn, and how they play their part to affecting your project’s success.
- Team dynamics refers to the way you work as a team. Consider the way your team is or will be structured – is it a flat or steep hierarchy (each has its own merits depending on the project)? How dispersed are your team members – across the world or a country, or in the same office? How many different organisations are represented in the project team (for example, is it a joint venture)? All such factors are constraints to manage.
- The organizational structure in which your project operates refers to the “larger structure” of your parent organization or organizations. Is it a functional structure, where functional managers have most say and power in how things are run, or is it a projectized or matrix structure where project managers have more formal power?
- Lastly, project implementation methodologies vary across different disciplines, be it manufacturing approaches such as lean thinking or Kanban/Just In Time, or IT processes such as waterfall or agile. Overlay onto that general principles of project management, such as project phasing and the structure of governance. Whichever methodology is agreed is a constraint to be managed.

In conclusion, managing project constraints of time, budget and scope is important, but managing these constraints effectively does not guarantee success in the eyes of all project stakeholders. Other constraints meld into these and affect a project’s success. We suggest that important other constraints for consideration on most projects are:

Aligning budget, schedule and scope to the overall benefits of the intended output
Measurement of Customer and Stakeholder satisfaction
Implementation planning to integrate the project into the organisation it is being delivered for
Managing risks (positive and negative) throughout the project
Managing team dynamics, the organizational structure in which the project exists and the project methodology used

Don’t forget to leave your comments below

Project Management and Firefighting; Are there Lessons to be Shared?

Written by Gareth Byatt on July 28, 2010. Posted in Articles. 6 Comments on Project Management and Firefighting; Are there Lessons to be Shared?

PMandFirefighting Soon after being accepted as a member of a fire department, cadets are typically enrolled into training classes. Their training regime may consist of basic classes, hazardous material teaching, awareness classes, and several others that are relevant to the challenging role of being a firefighter. New firefighters also are trained early in their career on communications protocols, the chain of command, and standard operating procedures. The need for a common communication language in the fire service is arguably more critical than many other professions, as the cost of a miscommunication can have serious consequences in an urgent situation. In most situations, there are procedures that every firefighter should know, and there are guidelines and processes that establish the chain of command. A system of protocols, chain of command, and standard operating procedures is needed so that, when called into duty, regardless of the department(s) or personnel responding, everyone knows what to do and who is accountable so that the teams can go straight into the “performing” stage of their activity.

Being able to perform under the tightest of pressures does not occur by accident nor by luck. Many fire services, especially volunteer services, employ an almost continuous training model where as much as 50% or more of their scheduled meetings are dedicated to training. Career firefighters also spend an abundance of time training, especially when first hired. Recent publications suggest on average 600 hours in formal training are required of new hires. These men and women are not just walking through motions in training exercises. To most, their motto is “train as you work” where every event is run as if it were a real live situation. When planning a response to a fire, the approach is to “Plan your work, and work your plan”.

So, how different is this from the approach we should take to project management? What lessons can be shared between project management and fire fighting?

For a project manager, regardless of the industry in which he or she works, many of the tasks in the early stages of a project are spent establishing the chain of command, project procedures, roles and responsibilities and “setting up the project for success”. A communication plan is developed and agreed on, implementation strategies will be developed and works planned prior to Execution. Project managers rely on organizational process assets (OPAs) to ensure they have appropriate project guidelines, which are often adapted to a project’s unique stakeholders. There is rarely a situation where every project team member knows the exact responsibilities for the entire project, but as good stewards of project management, taking the time to ensure everyone is clear about everyone’s role and responsibilities pays dividends, since studies have shown that most issues on a project can be traced back to misunderstanding and lack of communication at the right time.

Having every stakeholder fully aware of all expectations and the whole team quickly into the “performing” stages of a project would be a project manager’s utopia. How successful this goal turns out to be is based on several factors, but primarily on the organizational structure in which the project manager works. A fire department is an example of a “projectized” organization. Every call-out is akin to a project, with varying external stakeholders based on the callers. Because of the need to ensure communications of the team are paramount, a central resource/team is generally responsible for stakeholder management on scene which allows the “core team” to perform the essential services required to tackle the problem. These people within the fire service are commonly referred to Incident Commanders, Site Managers or other similar titles. What is important to note is that every team member responding to a call-out is aware of the expectations, which allows the core team to get straight into the “performing” position from the onset.

In conclusion, we believe there are some valuable lessons that can be shared between the way that a fire service deals with its situations and project management. We believe some approaches we should ensure are in place in project management include:

All new project team members should complete an “on-boarding session”, where they learn about the project, the team, the standards and communications channels and the roles and responsibilities of everyone. The better prepared our project team members are, the less time they need to spend in the non-value stages of storming and conforming. The sooner a team member is performing, the less risk there is to the project.
Ensure that the project team adopts a team attitude from the word Go. Project members should have project-driven agendas and a modus operandi that are aligned to the success of the project.
Every project and every project member should be aware of the Standard Operating Procedures (SOP). If they are not, the SOP, Communication Plan, Chain of Command, etc. should be covered in appropriate detail in the project kick-off meeting and with all new team members thereafter.
Always match the team to required skills and training, and ensure they are given the best training to perform. Team assessments that help show team members how to maximize their effectiveness as individuals and as a team are critical to project success – invest the time to conduct them early. Allow team members who have skills gaps to learn from more experienced members on the team, even more so if the team is expected to work on projects together in the future.
Always apply the same level of rigor to training and the general project teamwork set-up. This approach should ingrain the concepts, processes, etc., and for a project manager these activities should be second nature at the start of all projects.
Approach every project with a plan. Be willing to recognize when the plan is not working to expectations and take appropriate corrective courses of action. Fires are like projects, in that no two are exactly alike and are apt to changes mid course. In order to be successful, you must be willing to modify your plan during the course of a project.

Dedicated to all the men and women across the globe that freely gives of themselves to make a difference in the world. Special thanks to David Taylor of the Avoca Volunteer Fire Department. David is a 24 year fire service veteran; 18 of which he has served as chief.

Don’t forget to leave your comments below

Gary Hamiltonis 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.

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation. He’s a PgMP®, PMP® 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 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award. He can be reached through LinkedIn.

Anatomy of an Effective Project Manager

Written by Gareth Byatt on July 6, 2010. Posted in Articles. 4 Comments on Anatomy of an Effective Project Manager

anatomy It’s first thing in the morning, and you are preparing to interview prospective project managers for an open position on your team. Whether it is your first candidate interview or you have conducted many before in your career, you are likely to be contemplating the line of questioning you will ask of the prospective candidates. Perhaps you are thinking of questions from a “Strengths and Weaknesses: Project Manager Profile” that you typically use. However, any line of questioning can only provide a limited insight about the candidate and their potential to be an effective project manager for your organization. Understand that a skilled candidate may well have sat through similar interviews recently, researched your organization, and prepared competent answers to what they believe are the most typical interview questions. Or maybe they haven’t, because this is the first interview they are going to, although they are a first-rate project manager and well thought of in their existing organization. In order to assess whether a person has the potential to be an effective project manager in your organization, we contend that you need to conduct specific assessments beyond interviews and references of previous work assignments.

There is no magic formula for success in finding a project manager that transcends the needs of all organizations. A project manager who is highly successful in one organization or company may find limited success in another. Much may depend, for example, on how the organization sets itself up for running projects (strong matrix, weak matrix, projectized, or functional). Knowing how your own organization operates its projects is crucial to selecting new project management talent, and to making sure a new starter is not placed into a spot where they will not realize their potential, and the organization will not reap the maximum amount of benefit.

We believe there are certain personal characteristics/traits that, if present in a person, will make them more likely to be effective as a project manager in a variety of organizations.

We are putting forth what we believe are a set of core personal characteristics for project managers that, put together, can comprise a profile of an effective project manager for most organizations.

We put forward five core personal characteristics of effective project managers. These are:

Be an extrovert
Display personal courage (lead from the front)
Possess charisma
Be an enabler with a can do attitude
Have a strong sense of teamwork

Let’s cover these points in more detail.

First, the need to be an extrovert. It is commonplace for project managers to give presentations and lead work groups. After all, a project manager’s job is 90% communication. The audience for their presentations range from project teams to project sponsors and perhaps customers and/or investors. A project manager needs to be comfortable addressing any size of stakeholder and/or customer group in a wide variety of situations. An introverted person will likely have to undergo long-term training and coaching to come out of their shell in order to be truly effective in all environments. Extroverted people tend to exhibit a natural comfort in such situations and are at an advantage.

Next, the need to display personal courage. In many projects the project manager will need to settle disputes and differences of opinion amongst stakeholders. Negotiations can often be delicate, particularly at tight moments in the project’s life. The right decision is usually not one that is favorable to all stakeholders. An effective project manager should display personal courage in all decisions made, see them through, and ensure the team continues to pull together for the benefit of the project. Maintaining respect from all stakeholders takes skill, which can be learned through experience.

This leads us to charisma. A charismatic project manager is more likely to have others willing and wanting to follow their lead because they have faith in their leadership. More than likely the charismatic project manager is in a better position to mentor and train others.

Neither of these two core characteristics of courage or charisma is present in the core personality traits of all people, and it is important to tease-out how much of these characteristics the candidates you are interviewing possess.

Having a consistent can do attitude is akin to being positive on all teams, and always seeing a solution to a challenge or a problem. Such an outlook can make a huge difference in the face of road blocks when they appear. This positive attitude says a lot about the person’s character and how they will react to adverse situations.

An effective project manager while being results driven will also have a sense of team and enablement. He or she is focused on the team and the project over and above their individual needs. The project manager is continually encouraging the team to challenge themselves and to rise to heights that may even go beyond the expectations of the project (though not to ‘gold plate’ a solution, of course). To be effective, the project manager should consider the long-term relationships with the project team. If he or she is totally results driven, without a sense of team and enablement, sure, their particular project may get done within the project constraints, but at what price? And what if they have another project with the same team member(s) in the future? With a sense of team and enablement, a project manager is likely to be more effective in the long term. And people will want to work with them (even more so if they are charismatic and have a positive attitude). If your organization preference is to focus on each project by project without regards for the long-term, bringing in someone who is focused on ‘just getting the work done’ would be the best option, but nowadays this type of approach is rarely pursued.

In conclusion, we assert that there are five particular personal characteristics that can make a person effective as a project manager – the need to be an extrovert, to display personal courage, to possess a measure of charisma, to have a can do attitude and to be a good team worker. When these characteristics are present, along with core project management skills such as being a good organizer, being detail-oriented, and other discipline-oriented skills, the project manager is more likely to be effective across many types of organizations and industries.

Those who are making key hiring decisions for project management talent should consider appropriate assessments in addition to a person’s experience and interviews in order to gain a complete picture of potential project managers. Taking the time to select the right people can pay huge dividends.

Don’t forget to leave your comments below

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.

Minimizing SME Bias of Subject Matter Experts through effective Project Management

Written by Gareth Byatt on June 2, 2010. Posted in Articles. 2 Comments on Minimizing SME Bias of Subject Matter Experts through effective Project Management

“Bias and prejudice are attitudes to be kept in hand, not attitudes to be avoided.” Charles Curtis

The use of SMEs (Subject Matter Experts) is commonplace throughout the lifecycle of a project. The “experts”, as we generally refer to them, are typically functional experts in their respective roles that the project manager relies on for making delivery estimations and identifying potential risks to a project. Depending on the dynamics of your particular organization, such experts may come from the same functional team that will be responsible for the execution of the tasks for which the experts are providing input. On the other hand, they may be in a specialist division that deals with project set-up. In either case, there are a several risks which the project manager needs to look out for to avoid being given an impossible or very difficult delivery task.

In many business environments, the experts available for a project are often within the same functional group that will be responsible for the execution of tasks on a project. Let’s consider for example, Project Alpha. Project Alpha’s objectives include designing a new car headlamp for Automotive Company XYZ. The experts used for this project are likely to include engineers, managers and/or senior personnel from various departments that will be responsible for the development of the product. The potential pitfall in using experts from the same group that will ‘implement it’ is that they accept the estimates without accounting for any bias that may be lurking in the estimates. This bias may be consciously or subconsciously included by the experts. Once the scope and requirements have been finalized for the project, the duration estimates are generally finalized with the input of the experts. In order to meet or exceed the duration estimates provided, the expert’s estimates may actually be “worst case” scenario unbeknown to the project manager, which has ensuing implications on project budget and schedule. The “Peter Principle” risks coming into play, by which the work expands to fill the time available and we do not get the optimum delivery result. Conversely, estimates from experts which are overly optimistic risk putting the delivery team to the sword – and put the project budget at risk. The conclusion: project managers should make sure that expert guidance is “peer reviewed” by an external person to ensure it is reasonable.

Bias is not isolated to the work estimates of a project. It is also connected to the level of risk involved, whether for an estimate of work or generally assessing project risks. Risk, according to PMBOK, is calculated as Probability * Impact. Yet risk depends on the project team’s appetite for it – particularly the client, Are they risk averse or risk-seeking? Depending on the environmental factors of your organization, how you obtain the probability and impact may vary. However, most calculations of impact will be based on the subjectivity and experience of experts. Take the example below, where the project team has agreed that impacts should fall into one of five categories (see figure 1.1 below), and any risk rated over a 2.0 impact should require mitigation planning.

Assessed Impact	Assigned Impact Value
Less than 5% variance in Schedule/Budget	1
5.1-10% variance in Schedule/Budget	3
10.1-15% variance in Schedule/Budget	5
15.1-20% variance in Schedule/Budget	7
Greater than 20% variance in Schedule/Budget	10

Figure 1.1

Which category a risk should fall into requires a degree of subjectively from those assigning the rating; which in most situations involves expert opinion. If the project manager relies only on a few experts to assess impact, potential identified risks may be understated, remain un-mitigated (not acted upon) and later cause issues for the project. Equally, true mitigation factors may not be properly assessed (the experts will not know as much about the project’s situation as other members of the team, or other stakeholders).

What tasks or steps should a project manager take to minimize expert bias? The project manager should, where possible, draw on a pool of experts, who are not on the project team nor responsible for the project’s tasks, to validate the assumptions, estimates, and risks provided on a project. Using a pool of experts should be considered more carefully, especially if the project will employ contractors. If a pool of experts is not available, the project manager should use assumptions and constraints methods in calculating estimates to be included in the response, as well as having PERT three point estimation [(O+(MLx4)+P)/6 ].

In the calculation of risk, the project manager should not limit the input to that of experts. Building on the risk example above, the probability of risk B was calculated using Monte Carlo analysis to be 47%. What value should be assigned to the “Impact”? If the project manager accepts only limited expert input, there are added risks that the impact may not be accurate, thus not mitigated.

Risk	Probability	Impact	Risk Rating
Risk B	0.47	?	?

Figure 1.2

This article suggests that each project risk should be carefully assessed by the stakeholder group for the project. The ‘aggregated mean value’ of the assigned impact should be used to make a reasoned decision. Whether or not you weigh each of the stakeholder’s responses the same will be based on your organizational factors. If you do weight their responses, think carefully about whether the weighting should or should not be shared with stakeholders, as this can lead to arguments or disagreements. People may not like to know that their option is weighted less than another’s, but sometimes it may be necessary. Below is an example.

Stakeholder	Stakeholder Group	Weighting	Impact Provided	Impact Score
Ann Smith	Expert	1	5	5
Bill Jones	Customer	0.5	7	3.5
Chris White	Sponsor	0.75	10	7.5
			Impact score Aggregate Mean	5.33

Figure 1.3

If we go back and use the aggregate impact, we find the risk rating as follows:

Risk	Probability	Impact	Risk Rating
Risk B	0.47	5.33	2.5051

Figure 1.4

Summary
Using Aggregate Risk Rating, and putting in place “Expert Pools” are just a few examples of how project managers can take steps to minimize the bias of expert opinion in making decisions for their project (throughout the various phases), to make sure the overall project risk and estimates of work are reasonable for the tasks required. Using a simple risk table (Probability x Impact) to validate your information can help you achieve this in a measured way.

Don’t forget to leave your comments below

Jeff Hodgkinsonis 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 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award. He can be reached through LinkedIn.