Tag: PRINCE2

Ten Thoughts on Contracting Out Agile Software Development

Written by Richard Hoad on December 16, 2014. Posted in Articles. 3 Comments on Ten Thoughts on Contracting Out Agile Software Development

In my company, we operate IT projects under Prince 2 . For some types of software delivery we find agile methods are appreciated our customers. In these cases we use the two approaches in a complimentary way – software products of the Prince 2 project are delivered using an agile method. We find the sweet spot for Agile methods is in-house development where requirements are uncertain, there are changing needs and the development team size is 2 to 6 relatively experienced people.

The 2013 State of Agile Survey results give an industry wide view of the perceived benefits of agile methods, while Rico’s paper on the business value of agile project management , gives an overview of quantitative studies of the benefits. In terms of agile methods my company typically uses Extreme Programming and Scrum .

The advantages of agile methods that we appreciate are:

An agile development can effectively accommodate strict time constraints (by number of iterations) and budget constraints (the cost of the team for the number iterations) managing scope (which features from the backlog are scheduled) and maintaining required quality.
The discipline of delivering user valued functionality in time bound iterations manages many risks. In a project where the customer has tested and accepted deliveries every two weeks it is difficult to find a sign-off block towards the end. Any deviation from planned velocity is visible from the first iterations.
Detailed requirements analysis is done just in time so less time wasted in detailing requirements or features never built.
Early iterative delivery sometimes allows return on investment earlier.

We are moving towards contracting out a proportion of software development work. Traditional models for contracting out include time and materials and fixed price delivery. Most of us appreciate the risks of these extremes of the spectrum. In the first the supplier’s economic objectives are clearly not aligned with those of the customer. The second extreme favors inversion of the Agile manifesto ; focusing on artifacts, process and contractual negotiation rather than collaboration, embracing change and working software.

The question many ask is, can we retain the benefits of agile methods when contracting out software development? Others have studied this question including Abogast, Larman and Vodde . The following analysis derives from our use of agile methods in-house and in two tenders for software development recently conducted through the UN Global Marketplace .

The first lesson we learnt in contracting out agile software development (or anything else for that matter), is to align objectives of the supplier and the customer. It is highly desirable to align supplier success with customer success.
The key here is to define the product vision and what must be achieved; foster shared ownership of the goals by treating your supplier as a partner; and consider offering the supplier incentives for meeting key business performance indicators that require partnership with you.

1. In contracting out Agile software development, contract the product vision, define the desired end state and define how completion will be determined.

Define how the project is to be run. Tasks that are done repeatedly in each iteration or sprint become smooth and efficient. Tasks that are left as one-offs for the end of the project contribute to the, “ninety-ninety rule” , and those interminable delays that occur in the last 10 percent of the project.

2. As far as possible minimize the number of one-off tasks by doing them incrementally in each iteration.

Ideally delivered software should be integrated into your environment and your project management methods ready for you to take over control without further effort. We therefore recommend you make your toolset for software development (e.g. source code versioning, backlog management and continuous integration) available to the supplier and require them to use your tools from the beginning. If you have a deployment and quality assurance team, we recommend they do their part in every iteration. We recommend selecting suppliers with a strong ethos of automated testing and test driven development. There is nothing more frustrating for your users than finding the same regression errors in each iteration.

In terms of the agile method, the contract must establish key control points, e.g. how iterations are planned and accepted and the parts of the agile method are mandatory.

3. The contract must define essential process and toolset requirements without unnecessarily limiting the supplier’s freedom to work in the best way possible.

The contract appendices must define conditions for acceptance of each iteration. These will include the tests to be conducted and passed including user acceptance; the standards that must be adhered to (e.g. coding, security, architecture, look and feel, quality, performance, accessibility) and how they will be validated; and what documentation and knowledge transfer is required.

4. The contract must define the conditions for acceptance of each iteration and the overall product.

Do not throw away years of acquired wisdom when authoring the first contract for agile software development. Examine each of the boilerplate clauses your organization typically uses. Clauses on ethical standards, intellectual property, information confidentiality, and maybe even liquidated damages are as relevant to Agile delivery as to any form of delivery.

Related to this, the question of warrantee of delivered software often arises. We recommend warrantee only if the code will not be modified by other developers subsequently. Requiring warrantee will not make proposals cheaper, but proving that a bug derives from the work as delivered can be time consuming.

5. Do not throw away years of acquired wisdom when authoring your first contract for Agile software development.

Some argue that the supplier team membership should be formalized in the contract and changes should be authorized by the customer. On the face of it, this may sound attractive but it dilutes supplier responsibility for the team and the team’s delivery. Our recommendation is to contractually establish the customer’s right to authorize changes to people in customer-facing roles only, and specifically, the scrum master/leader.

6. The supplier should have the responsibility of providing a multi-disciplinary team capable of doing the job.

The contract must provide a mechanism to ensure that both parties are comfortable with the proposed scrum master or team leader.

7. The Scrum Master or team leader will probably be from the supplier side but supplier and customer need to agree that the Scrum Master is suitable and well qualified for the job.

The product owner is another key role and will be nominated from the customer side. They represent the customer and communicate the customer’s vision and requirements and most importantly, from a contractual point of view, ultimately control the backlog.

The Agile Manifesto says, “the most efficient and effective method of conveying information to and within the development team is face-to-face conversation”. Co-location of the team is therefore desirable but not always possible. Sondra Ashmore 2012 examines impact of process on virtual teams on agile and waterfall projects.

Embedding a member of the customer team in the supplier development team by mutual agreement is an often workable one fall back option. This gives the supplier team insights and interpretations; and the customer can get an early heads up of supplier side tensions and problems. It is important that these arrangements do not undermine the role of the product owner.

8. Ensure the product owner knows the Agile method in question, has a stake in the delivery and can dedicate sufficient time and energy to the project and assessment of deliverables. Contractually establish the role and responsibility of the product owner.

We recommend measuring progress counting only fully accepted features when they are accepted at the end of time boxed iterations. The contract must make provisions for how to handle issues such as higher or lower velocity than expected.

At a very basic level, specifying that iterations are time-boxed; setting a minimum proportion of features as a criterion for acceptance of an iteration; and making payment on the basis of accepted iterations or sprints offers the customer a reasonable degree of control.

9. Establish how progress will be counted, the rate of implementation will be measured and the payment schedule.

When software is delivered only after significant investment of time and money, early termination is a huge risk and requires a lot of attention in the contract. With agile methods it is still necessary to consider early termination but exposure is more limited.

Whilst an obvious option is symmetrical right to terminate after each iteration, such short notice may deter a supplier from bidding for, or committing their best resources to the contract. In long projects it may be better to define groups of iterations that arrive at a cohesive state as optional termination points.

It is also important to consider what actions are required with termination, e.g., what becomes of partially developed products or materials provided for the execution of the contract.

10. Establish conditions for early termination and what actions are required by both parties upon termination.

Regarding future plans, we aim to re-use the contracts we have and use lessons learnt to improve our future formulations. We would also be interested in hearing of your lessons learnt in this area.

Don’t forget to leave your comments below.

References
http://en.wikipedia.org/wiki/PRINCE2
http://en.wikipedia.org/wiki/Agile_software_development
http://stateofagile.versionone.com/why-agile/
https://www.projecttimes.com/wp-content/uploads/attachments/rico-apm-roi.pdf The Business Value of Using Agile Project Management for New Products and Services
http://www.extremeprogramming.org/map/project.html
http://en.wikipedia.org/wiki/Scrum_(software_development)
http://agilemanifesto.org/
https://www.projecttimes.com/wp-content/uploads/attachments/agile_contracts_primer.pdf – AGILE CONTRACTS PRIMER
https://www.ungm.org/
http://en.wikipedia.org/wiki/Ninety-ninety_rule
http://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=3267&context=etd The Impact of Process on Virtual Teams: A Comparative Analysis of Waterfall and Agile Software Development Teams

5 Steps to Build Confidence in Your Team Members

Written by Susanne Madsen on May 20, 2014. Posted in Articles. 1 Comment on 5 Steps to Build Confidence in Your Team Members

How do we build confidence in others?

As project management professionals, one of our most important roles is to bring out the best in our team. This includes not just building a great team, but encouraging collaboration and empowering people around us. We achieve this success by helping individuals improve their confidence and make them see that their contributions and talents matter. The rewards are big—from improved employee engagement and performance to increased productivity. Here are five ways to instill confidence in your team members:

1. Help people learn and develop.

Confidence and competence are closely related. If team members feel that they’re not developing professionally and that their skills are being under-utilized, they’ll quickly begin to doubt their abilities. To increase your team members’ confidence, you have to help them improve and learn new skills so they can play a stronger role in contributing to the project.

One way of doing this is to give your team access to courses, training and conferences. Another way is to give them time to study or to run a pet project they’re passionate about. You can also set up knowledge-sharing sessions to the benefit of the entire team, or even the entire department.

2. Delegate step-by-step.

A great way to build up your team members’ competence—and thereby their confidence—is to delegate specific tasks that will help them grow in an area they’re interested in. Just be careful that you don’t delegate too soon or too quickly; and don’t leave people to their own devices when they’re in new territory. When someone lacks confidence and competence it’s far better to gradually give them more responsibility and to stick close by them until they no longer need you. Your job is to help you team members set reachable goals and to break difficult tasks into smaller steps. In that way people slowly but surely gain confidence as they start to master each step of the assignment.

3. Focus on people’s strengths.

As a project manager or team leader you’re likely to have a fair bit of influence over who does what. You can use that to actively build up someone’s confidence by giving them work that they’re genuinely good at and interested in. People’s confidence (and motivation) will generally grow when they’re given the chance to put their skills into practice and show mastery. The question you need to ask is: How well do you know each of your team member’s strengths. To learn more, check out Tom Rath’s best-selling book, Strengths Finder.

4. Be supportive.

One of the most fundamental ways to boost people’s confidence is to actively support them and build them up emotionally. And one of the best ways to create a strong supportive foundation is to connect with individuals one-on-one. When you do, make space to sincerely listen to their concerns and help them realize how much they have to contribute. When you get to know the members of your team at a more personal level (e.g., what motivates them; what really matters to them) you’ll intuitively know how to best support them.

Another way to demonstrate your support is to actively praise a team member and provide positive feedback when someone does something well. We all like to feel appreciated and it takes so little to say “Thanks, that was a superb job you did.”

5. Embrace failure.

Another great way to build people up is to let them know that it’s OK to make mistakes—as long as they don’t keep making the same ones. When you remove the fear of failure you make people feel safe. As a result, team members open up and are more willing to contribute and experiment. Knowing that they have the space to learn from their mistakes rather than being penalized for them builds their confidence and takes away an enormous chunk of negative energy and worry. Essentially, you free people up to pursue that which is truly important: The successful delivery of the project.

Don’t forget to leave your comments below.

An Executive Perspective on Project Sponsorship

Written by Abid Mustafa on June 12, 2013. Posted in Articles. 5 Comments on An Executive Perspective on Project Sponsorship

Over the past decade or so, I have been involved in project work performing a variety of roles. I have led the enterprise PMO and played the role of an executive sponsor, yet there still exists a wide spread perception that executives do not do enough to support the delivery of projects.

The gap between perception and reality regarding strong executive sponsorship for project work is closing but not fast enough. I’ll be the first to admit that executives can do much more to play an instrumental role in seeing projects through to the very end. But project teams must appreciate and understand that executives have a tough job at hand.

In addition to project work, C-level executives in general have to manage corporate strategy and departmental plans, commercials and contracts, financials and budgets, people and technical resources, administration and logistics, and last but not least office politics. Striking the right balance between project sponsorship and these activities is extremely demanding, and all too often the work load takes its toll.

Nonetheless, this should not serve as a pretext for executives to become inactive spectators when sponsoring projects. On the contrary, it can be argued that by managing the company’s work in terms of projects and programmes, executives can optimize how to manage their work load better.

In this article, I would like to address some important points based on my experience that can help executives become good sponsors by providing the right environment for project teams to deliver successful projects and programmes

Sponsorship must be limited to a few key projects
The practical reality of active sponsorship requires executives to be engaged in less not more project work. Challenging projects and programmes are often taxing on executive time as they involve several meetings to resolve key issues, make intelligent decisions and provide guidance to project teams. This means that executives at best can get directly involved in two or perhaps three— at best—large projects or programmes at any given time. To expect executives to take on more than this runs the risk of executive fatigue, disengagement and in the worst case lip service. To mitigate such situations the company has to strike a fine balance between its aspirations and its capability to deliver. By introducing a proper project portfolio management methodology and recalibrating the mindset of the company to do less, executive sponsorship will invariably improve.
Learn to use the right language to communicate project work to executives
One of the persistent challenges that project managers and their teams fail to overcome is ineffective communication with the executive audience. A parlance that is heavily laced with project management terms can be quite off putting and only serves to entrench misunderstandings regarding projects. Likewise content that is heavily immersed in details produces the same negative connotations. Project managers and project teams must communicate in a language that the executives can understand. This should not be misconstrued as using only financial terms to communicate project status updates. Instead, project managers should present project updates by employing terms that the collective executive audience is comfortable with. For example the chief technical officer (CTO) is in a better position to understand project information if the content employs technical terms that the CTO is familiar with. Similarly, the chief financial officer (CFO) will be more receptive if financial terms are used to convey the project information. Hence it is vitally important for project managers and their teams to get to know their executives and how they think and communicate. This will help in the reduction of the communication gap, and through experience, project managers should be able to communicate effectively with the executives.
Thoroughly prepare for executive meetings
There is nothing more annoying to executives than to attend project steering meetings and discover that the content is not thoroughly prepared or well researched. Poor content means that executives will be turned off, vital decisions will get delayed and projects will not move forward. Additionally, when issues are discussed it is always helpful to show the root causes accompanied by several solutions. All of this helps executives arrive at decisions swiftly thereby minimising the need to have lengthy meetings to clarify the content and explore solutions from first principles.
Always assume executives need to be educated on project management
Project managers and their teams make the mistake of assuming that executives are fully conversant with the discipline of project management and are aware of the latest trends such as adaptive project management. Nothing could be further from the truth. Executives need to be constantly educated about sound project management concepts, tools and techniques. For instance complex projects require a slightly different approach to conventional projects. Executives will to understand the importance techniques like tracking known unknowns or the rolling wave plan.

Where appropriate, executives should undergo professional training to enable them to speak and understand the same language as their project teams. Training could be in the form of industry professional project management courses such as PMP or PRINCE2, or customised in house courses specifically design to instil project management concepts within the operating environment of the company. Project managers should exploit every opportunity to encourage executives to learn more about project management. Strong persistence in this matter will eventually pay off.

These are just some of the points that I believe will help both executives and project teams improve executive sponsorship. In the end, executive sponsorship is a two way process that requires strong participations from both executives as well as project teams. This is a long journey and there are no easy short cuts.

Don’t forget to leave your comments below.

Benefits Management – the Key to Success in Project Management

Written by Andy Trainer on October 10, 2012. Posted in Articles. 4 Comments on Benefits Management – the Key to Success in Project Management

As mentioned on the official APMG description of PRINCE2, one of the things that makes PRINCE2 stand out from other project management methodologies is the focus on continuous improvement and the importance of the viability of a project – the project lifecycle doesn’t stop when the product is delivered.

Benefits should be included in the business case of a PRINCE2 project, but are often a tricky factor to define and manage. The reason for their importance is because, although the project is undertaken to produce a product, what the business actually wants is the benefit of that product. E.g. if it’s a new product for sale, the benefits are the sales from the product. If the project is to develop a new content management system, that system needs to make the business more efficient and therefore save money.

Documenting clearly defined benefits can also help ensure buy-in from everyone working on the project – team members’ doubt in its value can be damaging.

It’s crucial that a project manager questions the customer on the benefits they expect once the product is delivered, and moving forward from there. Delivering a successful project blind to expected benefits could mean miscommunication and, ultimately, undeserved damage to the project manager’s reputation in the eyes of the customer.

Consider this story, we’ve all heard similar tales but this one in particular was relayed to me by one of the delegates on our PRINCE2 training course just last week. They had been asked to manage a project developing a new CMS and were given very specific requirements for how they’d like it to work. The project manager delivers this product as specified – but it transpires that the new system is harder for the users to manage which means none of the assumed benefits are achieved. The customer blames the product and, by association, the PM.

Now, this individual came on our course for all the right reasons – they realised that working under a specific project management framework would mean that issues like this could be avoided. But it got me thinking about benefits and the responsibility of the PM to manage these. In essence, benefits realisation management is about outcomes as opposed to outputs.

How to Realise and Manage Benefits in PRINCE2

A useful way of helping the Customer or Senior User to identify expected benefits is by using the 5 Whys method of root cause analysis, a technique used in Lean Six Sigma. Asking the Customer what they want (a new product), why (they don’t sell this but others do), why (if other people sell it, it must be in demand) why etc.

Usually, the Senior User will specify and defend the benefits – this will form the basis of the business case. They will be in line with the business’s high-level strategic objectives, and any benefits management done as part of programme management where relevant. The inclusion of the end user in the PRINCE2 process is another key to its beauty and popularity.

In PRINCE2, the Benefits Review Plan is put together by the Project Manager in the initiation stage of the project. This will document the following:

The expected benefits as outlined in the Business Case
How these will be measured objectively – and against which base line value from before the project was initiated
Who will measure the benefits (usually the Senior User)
When they must be measured (sometimes some benefits will be achieved while the project is still ongoing) The Project Board must agree on how far along the line the benefits will be measured once the product has been delivered.
Tolerances
Dependencies
Disbenefits

Once created, the Benefits Review Plan will be submitted and approved by the Project Board. It is revised at the end of each stage within the project, usually with separate benefits for each stage of the project.

During the final benefits review, the Senior User will identify and evidence benefits that have been gained.

Dis-benefits

It’s a clumsy term but is used in the PRINCE2 manual to describe how benefits must always be managed alongside expected negative outcomes. For example, perhaps the new CMS will run much more quickly but require more maintenance. A very common dis-benefit is a reduction in productivity during the time taken for users to learn to use a new software product.

Dis-benefits are not the same as risks. Risks are outcomes that might occur, and dis-benefits are outcomes that have been identified and accepted as very likely or certain consequences of the project and its product. Of course, dis-benefits should be analysed to ensure they will not outweigh the benefits!

Dependencies

Benefits of a product will always depend on more than just the delivery of the product by the project. The benefits will depend on such things as effective implementation of this product, which may or may not fall within the project remit.

Dependencies are very important when it comes to identifying where the line of responsibility is drawn. Other individuals or organisations are often dependencies, e.g. the supplier providing the right goods at the right time, or appropriate trainers being available if the project is delivering a new piece of software.

Why Benefit Management is the Key to Project Management

No matter how closely you follow the rest of a project management methodology such as PRINCE2, if the ultimate goal is misguided then it will be hard for anybody to consider the project a success.

Project Managers need to be remembered and reemployed for delivering results, not just products, so it makes sense for responsibility for benefit realisation and management to fall within their hands.

Don’t forget to leave your comments below.

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

Written by Mike Morton on September 26, 2012. Posted in Articles. 5 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.