Tag: PRINCE2

Is Accountability a Key Component for Project Management?

Written by Lisa Anderson on August 22, 2012. Posted in Articles. 1 Comment 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. 4 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. 2 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. 3 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

Has The Economy Changed How We Do Projects Forever?

Written by Jim Hannon on September 7, 2011. Posted in Articles. 8 Comments on Has The Economy Changed How We Do Projects Forever?

Sept7FEATURE In the continuing drumbeat of bad economic news over the past month, there is a fundamental underlying shift on how this economy has impacted project selection and execution. This is also an excellent opportunity for the creative risk-taking PM to gain a career advantage and strengthen the role of the PMO in today’s companies.

Trend Number One: Companies want to do more with less

We have all seen this trend and unfortunately some of us may be among the casualties of this trend. I advocate that Project Management is more important than ever to fully understand how we do the basic package of work in business: the project. I want to be clear in this area: the PM must be a hands-on PM not an administrator. The company needs to have a cost and

efficiency watchdog in the project and the PM should take on this role. In the majority of companies, the first question a new PM should ask is, “How many projects do we have ongoing?” I guarantee the answer is usually, “No idea!” I always find it amazing a company will spend the treasure of the company and have no idea what they are spending it on, but always think PMs are too costly! The PMO should also be at the vanguard in advocating the proper allocation of resources and ensure that a constant return is being delivered in each project

Trend Number Two: Trust has gone out the window

In today’s project, the team constantly hears of layoffs and constantly lives with the thought, Am I next, no matter how talented you are in your job. This trend may be very pronounced in your company or it is lurking under the surface and senior management does not want to acknowledge the issue. This trend is probably the most troubling today and will have a long-lasting impact. The members of your team may believe that creativity and thinking outside of the box is too risky and will open you to being on the layoff list. The team may also believe that they should not help other members of the team, and worse they believe that making the other person look bad is the best offense and takes the harsh light off them and their tasks. The PM must address this head on with the appropriate managers and get a solid buy-in from them as these petty issues will not be tolerated in the project. The PM along with the managers needs to then deliver that message to the team and all be held accountable if issues arise. The key here to remember is that TRUST=PRODUCTIVITY.

Trend Number Three: Give the customer their money’s worth

In many projects over the years, we all had the proverbial “day two“ list. In the new economy, the customer not only requests but demands their money’s worth. I am not advocating you throw to the side the idea of scope creep, but why would you now need to set a clear standard that a small change you classified as day two before needs to be completed to ensure the future revenue stream with the client. The PM must ensure the deliverables are fully documented and the communication is solid from all ends of the project so expectations are clearly set on what is being produced and when…

Trend Number Four: Will companies ever undertake a large project again?

We have all been involved in the large mega project and wondered quietly, How can this ever be done on time, within budget? I am a practicing PM and I sometimes question the project fundamentals of these projects so a senior manager who is not a project person has even more doubts. I believe mega projects will not go away but funding will be more difficult, and PMs will be held to a much higher level of responsibility and be measured on the triple constraint. I also believe that as PMs, we need to advocate for strict approaches where we do wave planning and break projects into smaller components. I fully recognize the need for an agile approach, but please do not be enamored by phrases. The bottom line is you have to do the work the most efficient way possible.

I realize there are other trends but this article is meant to stress that in a down economy, strong Project Management is even more crucial to the execution of the company’s business strategy.

Don’t forget to leave your comments below.

Jim Hannon has over fifteen years of diversified experience in the Information Technology and Financial Services Industries, functioning primarily as a Senior Project Manager/Lead Business Analyst/Program Manager with proven experience in trading systems and numerous financial applications domestically and global. Jim currently holds his MBA, PMP, PM-RMP and is certified in Prince 2 fundamentals. Jim is planning on sitting for the PgMP and PM-SP in the next 6 months. Jim also teaches Project Management at Boston University and Excelsior College and created the PM program at Excelsior. Jim is also a Senior Professor at Cambridge College. Jim works for a major IT firm and also has a consulting firm The Bentley Group, which offers PM and Business Analysis services.