I had the pleasure to be a guest lecturer recently for a project management fundamentals course at Trent University in Peterborough, Ontario. While I've lectured in this way many times over the years for many different institutions, I was struck by the unique approach that this course used for teaching the project management basics.

There is an interesting shift underway that has a profound impact for the project management community. Up until the past few years, the project management community has been focused on "basic training" and getting new PMs ready to write the PMP exam. While some industries such as engineering, procurement and construction have an overall higher project management maturity level, the fastest growth over the past couple of decades has been in the information technology industry, where a majority of organizations are small with a low level of PM maturity. PM publications and conferences have been mostly focused on serving these "new" IT PMs with novice (and a small amount of intermediate) training.

1. It is best not to share the project plan with the project team as it leads to unnecessary and usually incredibly stupid questions.

I find it amusing that the two words, “Project Manager”, mean such different things to different executives. After all, with the staggering success and proliferation of the PMI’s PMP designation and the highly projectized workplace of today, arguably, it should be as clear as a description of most organizational roles out there.

Termination of a large active project is like undergoing root canal surgery - intellectually you may realize that you need to have it in order to avoid serious long term impacts but that does not help to reduce the trauma associated with the event. The Kübler-Ross model of how individuals deal with traumatic situations (http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model) is apropos when understanding the personal impacts of project termination. In the economic rollercoaster of the recent past, we have all likely experienced the fallout of having the plug pulled on a project into which we had invested significant blood, sweat and tears (whether as a project manager or a team member).

You will be hard pressed to find a person that has taken some project management training who has not drunk the purple Kool Aid called Earned Value Management (EVM). You may have run into EVM "evangelists" at project management conferences or symposiums. You can recognize them by that glassy stare that comes from rolling up one too many work package cost calculations and you may have even learned to run for the hills when they have cornered some neophyte who expresses ignorance about the whole concept or (worse) challenges its practical applicability.

We've all been there - you've just completed a significant project, you assemble the remaining members of the project team (those that are still sane), the sponsor (if one exists) and the other stakeholders (those that still like you) and you conduct a post-project review. You dutifully ask each participant to think back over the lifetime of the project (which sometimes feels like the lifetime of the participant) to elicit any useful information that could be applied to future similar projects. You capture these lessons "to be learned" in a document and archive the document (similar to the Ark of the Covenant in the first Indiana Jones movie) knowing that it will never be seen by human eyes again.

(This blog first appeared in the Business Analyst Times, May 19 posting)

So you've been tasked to get requirements on a strategic project, and you're thinking to yourself, "How can I make my business requirements documents as incomprehensible as possible?" Going this route may not be just a job security thing. Making yourself indispensable as the interpreter of requirements seems to be the traditional route of delivery and getting buy-in. Just keep running the requirements process until someone gets desperate and finally signs off on the spec in the vain hope of getting something useful for their effort before the end of Q4 2014.

In my last three blog entries, I addressed some project management issues as they were happening to me, thus postponing my series on the rules of LPM. I continue here to expand my set of "rules". I will conclude the series with this 8^th rule, probably not the last word on this, but the essence of LPM as I see it...for now.

At the end of many of my project management workshops, I discuss project or phase closing and the notions of post mortem and lessons learned.

Since 2006, I have been giving project management courses as part of a master degree in "Management by Project" for three associated French engineering schools, in Lyon, Rouen and Aix-in-Provence. This master program is being extended to two new schools next fall, Nancy and Toulouse and in 2010 to Paris and Nantes. I might end up passing more time there than in Canada to coach and teach project management.

Opening, Adapting and Closing Often

I continue here to expand my set of “rules” of Lean PM, following Hal Macomber’s comments on my original four rules series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Rolling the Waves

My little series on the rules of Lean Project Management was supposed to end with Rule No. 4 (Humans, Humans, Humans) discussed in this blog last October. However, I will now expand my set of “rules” following Lean Project Management specialist Hal Macomber’s enlightening comments on my series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

“Project Quality Management must address the management of the project and the product of the project”

(p.180, PMBOK, 3rd edition)

In an earlier blog entry, I presented the Nine Wastes of Mismanaged Projects, according to Lean Project Management gurus (Howell, Macomber, Koskela, Bobek). I said then that I saw a 10th waste adversely affecting project success: Not Managing Perceptions. Today, I will briefly explain why I believe that not managing perceptions is a major project waste, and why it has to be taken care of for our projects to be successful.

Claude Emond’s Monthly Blog
The true “WHY” of project management: it is not about delivering on time, on cost and on specification!

I was a member of the Core Leadership Team responsible for the development of the PMI new standards released in the spring of 2006: The Standard for Portfolio Management and The Standard for Program Management. Actually, as one of the main co-authors of the portfolio standard, I had not spent much time looking at the Program standard. I was, however, receiving occasional emails on the Program Management standard development. I remember seeing an email trail including heated arguments about stating or not stating that projects had to do with generating benefits. PMI’s official position at the time was naturally coherent with the latest PMBOK version! The final word on these arguments was to include in the Program Management standard an artificial distinction between managing projects and programs, stating that (extracted from what I call the infamous Table 1.1, page 8 of the Standard for Program Management):

Claude Emond’s Monthly Blog

I am a proponent of using lean and agile project management concepts, whenever the context calls for them, be it on part of a project or the whole of it. I don’t care if the project is a construction project, a software development project or the implementation of a PMO. The original agile philosophy, that I espouse, is the following: "To every project its own methodology”.

Claude Emond’s Blog, SURVIVING THE PROJECT AGE, in which he shares his views and ideas about project management - and invites you to share yours

“Perfection of means and confusion of goals seem, in my opinion, to characterize our age.” (Albert Einstein)

We live in the Project Age. Projects are everywhere, used as means to adapt to and succeed in our exciting, ever-changing uncertain world! To succeed, we need to communicate better; this is not what the concept of “positive risk” is doing for us!

This is an experiment for me. I will try a two part blog, and see what type of feedback I get in between the blogs and attempt to incorporate some of that in the second blog. Please let me have your thoughts at hans.jonasson@jtcunlimited.com.

Scope creep tends to be one of the most common problems in projects. We are very focused on minimizing scope and then trying to stick to it. Well, one alternative can be to try to do scope creep upfront, before we sign the contract with the customer. A few years ago I began a long overdue kitchen remodeling project. It is one of those projects that lends itself very well to scope creep (or in our case, scope leap).

How's that for a heading? Exaggerated? Cheap shot? Maybe, but probably also with a bit of truth. Opening the PMBOK 4th edition I saw that PMI has added "Collecting Requirements" to the core processes and this immediately made me very uncomfortable. I have been in the PM business for 20 plus years and in the requirements business even longer, and I have always talked about the importance of separating the ownership of the product definition from the ownership of the project execution. The ownership of the product definition lies with the customer, or the buyer. They are the ones that must define what they want, the capabilities and functions that they are looking for in a product. The project manager represents the seller, or the developer, and as such their interest is often in direct conflict with the buyer.

Planning Business Analysis Work

When I first read the BABOK® Guide, my initial reaction was, "What are they thinking?!" With my PM hat perched squarely on my head, my reaction was "but... but this is PM work!" In my mind I imagined all kinds of conflict occurring as the BA took on more and more of the PM role. After all, as a PM I had done such traditional project management tasks as creating work breakdown structures, activity lists, estimating, scheduling, and now a body of knowledge was saying that the BA was supposed to do this work? I could see heads butting already.

At a recent conference I sat next to a project manager who observed, "My organization hired a new consulting company to do business analysis work. They've completely taken over. Now they do a lot of the work that I used to do, such as meeting with the sponsor to uncover the business problems, determining what we're going to do on the project...I can't believe it! I feel like I'm being treated like a second-class citizen!"

A recent failure of a 60$M telecom project invites the question of why?  The answer:  poor leadership.

But this answer is too general.  It doesn't really help us understand what we can do as project leaders to increase the likelihood our projects are successful.

IT projects usually represent change, so why aren’t there stronger links to the change management process at the formative stages of projects? Is there benefit to connecting the dots between business case approval, aligning the project portfolio with corporate objectives and change management? You bet there is!

There are many who would say that business cases need to be approved based solely on the merit of their benefits, costs and the risks associated with them. This isn’t wrong. But just because it passes this bar doesn’t mean the project should be given authorization to proceed. To make it onto the project roadmap the investment needs to be both viable and fitting to the organization. What does it mean to be both viable and fitting? It means that not only does the economic upside of the project have to be good enough, but the organization must also possess the ability to do the work (or get someone else to do it) and to make it pay off.

This will be my final blog for Project Times. It has been a great experience for me to write monthly on various topics and various experiences in project management. Over the past two years, I have been fighting the urge to call myself a project manager because I did not want to be pigeonholed as someone that can only manage projects. I wanted to be known as a consultant who also does project management.

As PMs, we are sometimes asked to lead or participate in the RFP process. For those not familiar with this process, it is a formal process used to select a particular vendor (or sometimes vendors) for the purchase of specific products or services. So what makes an effective RFP process? Well, first we need to answer the question ‘What is the impact of running an ineffective RFP process?’ It is the same as making a bad investment decision, because you have to live with the consequences of your actions. The main reason for these ineffective processes is bad evaluation criteria. Too many companies spend little to no time up front in determining the appropriate evaluation criteria and identifying the appropriate team members to evaluate RFP proposals. An effective RFP process will lead to increased value for your organization and ensures that you are selecting the best strategic partners for your organization. There are three things to focus on to run an effective process:

Why is this the first question that PMs get asked when someone is looking to bring someone in to manage a project? What happened to the days when skills and ability mattered? What about the need for someone to bring value to the project and see it through successfully? Has that all been trumped by the hourly or daily cost figure? It sure seems that way.

How many of us have been brought on to manage a project where the contract for the product or service was signed just before we started? Many of us, I imagine. And how much fun is it to review the contract on your first day and realize what your client or organization has agreed to? Then it is even more fun once you realize that, as the PM, you will be responsible for managing that contract. Happy days are here to stay!!!

Andrew Miller's Monthly Blog

I am going to let you in on a little secret. There is one area on which few projects spend the appropriate amount of time and all projects should: communication.

Now, you might be thinking to yourself that this is a ridiculous comment because on projects we are communicating all of the time in meetings, through email, on the phone. Have you ever been on a project where you got towards the end of the project and one of the stakeholders delays further work because they were unsure of the direction of the project? What about dealing with a multi-facility implementation where employees at different facilities have a different expectation of what is being delivered? How about implementing a fancy new software system only to find out that the way the system works will not support the daily operations of the business that purchased it? I am sure that most if not all of you have experienced something like this.

From PMI Network to blogs all over the web there is a continuing debate over Agile project management. I find it interesting, if not distressing, that the debate still rages. While there are distinct attributes of Agile methods, overall the basic tenets of formal PM are certainly there. Planning exists, there is a clear point of responsibility and accountability, there is monitoring and control (often a lot tighter and more useful than in more traditionally managed projects) as well as a closing. The predominant differences are in the way these are accomplished and the "weight" of the PM activities. The Agile Manifesto values some things over others, for example "individuals and interactions over processes and tools". This does not mean it seeks to eliminate processes and tools. Valuing the ability of "responding to change over following a plan" does not mean never following a plan. The Manifesto's writers were not fundamentalists, "black and white" thinkers.

A big issue in and around project management circles these days is how to manage effectively in the face of tight budgets and fewer human resources.  Do you cut back on PM activity to save resource time and money?  Do you have project managers wearing performer hats while managing?  Is this an opportunity to make the PM process Lean?

This is my first blog for Project Times. I am looking forward to sharing my thoughts and experience each month and engaging in a dialogue on project and program management and process optimization. The goal is to help in the ongoing work of optimizing our performance and the performance of our organizations. My orientation is influenced by systems thinking as a means for remaining objective and realistic. I promote open-minded mindfulness applied at the individual, team and organization level as means to optimize performance.

Aim low – deliver high. There I’m done!

Actually it seems simple doesn’t it? But let me tell you where it can go very wrong:

• You never ‘aimed’ in the first place – so no one, especially you, knew what to expect.
• You ‘aimed’ – but you never communicated it to anyone. Whoops!
• You aimed nice and low and delivered way high – great but what kind of planner does that make you?
• You aimed well, you communicated the plan really well to start with but you never got back to the rest of us to tell us how it was going... therefore denying us an opportunity to adjust our expectations.

As I sit on this flight from Sydney, Australia to Wellington, New Zealand I am thinking about the Business Analysts I met in Sydney and Melbourne and that I am about to meet in Wellington at two day symposiums I am running for BAs in each city.

These folks are really struggling – for recognition, for job security, for a well defined career path and for a recognized set of defined core competencies.

The summer is finally here! This is the time of the year that I try to relax – but I do find it difficult.

This is the time of the year that I plan, meet and regroup. I schedule all my team meetings for the summer months (working around everyone’s holidays) and review the past, look at the current status of work in progress and plan or re-plan the next few months.

When people in the project management business talk about risk, we think about the traditional role of risk management within a project

It’s April 28 and I am sitting in a breakout room at ProjectSummit * BusinessAnalystWorld in Philadelphia, PA – our first event in this beautiful city – and thinking about the keynote we just heard as well as the keynotes at our Toronto event two weeks ago.

There are some very strong messages in all of them.

David Barrett's Monthly Blog

Let’s start with… PMBOK is not a methodology – it is a body of knowledge. Many organizations in North America have spent a lot of money training their project managers on the pillars of knowledge as described by the Project Management Institute. This is a good thing. I liken this to the knowledge we all gained between grades one and 12.

David Barrett's Monthly Blog

I met someone the other day who was asked to roll out a PMO at a large financial institution. I was really impressed with her story.

The interesting part was not what she created but how she created it.

David Barrett's Monthly Blog

Sounds simple. Almost sounds too basic. But in my travels I can tell you that this is the biggest issue that project managers have. Scheduling is easy. Balancing resource loads is tougher. Managing scope creep is tough and getting tougher.

But in the end, it’s the people that make the job the hardest. If you do not know how to manage people, work with people, deal with stakeholders, talk to senior management – then I think you are in the wrong business.

Wow – that was a long flight! But well worth it. If you live in Australia- good on ya mate! If you have never been – you must – it is beautiful.

While I was there to run our new event for BAs in Sydney and Melbourne I came into full contact with the project management community there.

I got involved in this business of project management nearly 12 years ago. Quite a good story some tell me. But I think what amazes me still today is how this business has grown.

Many said back then that it was just a ‘wave’. Some of the ‘older’ PMs, the ones who were there already, suggested that the boom was just a fad. They could be heard saying that technology projects were not large enough nor important enough to warrant a seat in the professional world of project management.

Man, were they wrong.

But very interestingly, while the ‘boom’ in interest in project management has come from the technology sectors over the past 10 years, I am seeing a renewed interest in formal project management from the more traditional sectors: engineering, construction and aerospace. It’s almost like they woke up over the past year and said “maybe we were wrong to stop learning about project management. Maybe we don’t know it all."

And then as our classrooms and conference isles site more of this more established set, we see a whole new crowd of ‘kids’ take a major interest in project management. I write this as I fly home from Vancouver – the home of over 10,000 employees working in the Gaming industry. Video games. And guess how old this group is? Young. Very young. This groups looks on the 30 something crowd of PMs as old, established and traditional.

So what am I getting at? I think that the most fascinating part of this business over the next 10 year will be the growth – from all sectors, the hand off from the old to the young and the challenge we will all have to address the needs of all of these communities.

David Barrett