The tree swing analogy first came out in the 1970s and many variants came later on different subjects, such as software and management. It depicts the difference of how each department interprets and implements a requirement in the development of a tree swing. The variation of the cartoon on perception gaps in software development projects first came out in 2003. Then it became popular among the management to address issues when projects did not go the right way.

The Canadian government has created a new law (Not For Profit Act or NFP Act) governing federally-incorporated not-for-profit corporations (such as PMAC-AGPC), which requires us to pass some motions and submit some paperwork to them before October 17, 2014, or the organization will be dissolved. Read on for details... PMAC-AGPC needs to: · replace its letters patent with a Certificate of Continuance (Form 4031), along with Form 4002 · change the bylaws to be compliant with the NFP Act · approve the new articles of continuance and the new bylaws by 2/3 majority at the annual general meeting, · Submit Forms 4031 and 4002 and the new bylaws to Corporations Canada. To meet these requirements the following two motions will be made during the AGM: Motion 1: to authorize the directors of PMAC-AGPC to apply for a Certificate of Continuance

Project Management and The Human Resource Most project managers in industry have a technical education and are good technically at what they do. Since they are good technically, management feel they will be good as project managers, but this not necessarily so. Sure, they can figure out how to scope, schedule, and budget but, they fall down when it comes to the management of the human resource. People Are Complicated?

Why Struggle Why would you put time money and effort into our workshop without a clear payback? Most people do not have a clue as to what the payback is. For most of the participants, it is confidence. If you are starting out in project management you struggle as you are just not sure that what you are doing is correct. You know some stuff about project management but you are not confident about your knowledge. This workshop is all about building your self-confidence in project management. Sure, you can read books, take on-line courses, and build up your knowledge, but most people need to be with real people. You need to understand not only your own strengths and weaknesses but to see the strengths and weaknesses of others as well. You need to realize that you are not alone. In this live workshop, you will lean things you could not have learned at home. I Need To Get Away

Figure 1 is a picture of a rail loading terminal at a remote refinery. The yellow pans on the rails are the spill containment system. Each pan has a drain outlet on it that feeds into an underground drainage system and into a sump. The refinery loaded fuel into the rail tank cars here and shipped the fuel to an ocean terminal about 150 miles away. There the tank cars were unloaded through a bottom valve on the tank car. (The next time you’re sitting at a railroad crossing waiting for the train to go by you can see the bottom valve/outlet on some tank cars and not on others. The ones that don’t have bottom valves are unloaded from the top. It all depends on what is being shipped.)

Figure 1

In early 2000, the federal government required refiners to remove sulfur from the diesel

Project management has always come easily to me. These days, I write about it, teach it, consult about it and coach it. Hang around me long enough and you’d be forgiven for thinking that I was born with a spreadsheet clutched in my tiny red fist. However, it wasn’t until almost twenty-five years into my career that I really began to question the way the work I did got done and, most importantly, how I attacked problems and issues. During this same time, I came across Daniel Goleman’s first book, “Emotional Intelligence.” This was the book that ignited my quest for concrete answers about how we think, what role emotions play and how both of these dimensions affected the way we perform in our jobs.

The Top Reasons Projects Are Unsuccessful

By Richard Morreale

Over the years, I have been asked to review and audit many projects—projects showing signs of trouble, projects in what could be considered “terminal trouble,” and projects that had already given up the ghost. I was asked to do this for several reasons. The first was to see if the projects showing signs of trouble were really in trouble and, if they were, what we could do to keep them from going terminal. The second was to see if the projects considered in terminal trouble really were terminal and if there was something we could do to save them. And the third was to see what lessons the organization could take away from the projects that had already given up the ghost, so the mistakes made on that project weren’t made again.

By Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
and Mike Bowler, CSM

In a recent article titled “Agile Methods and The Need for Speed”, the author notes that many people are adopting agile development methods in hopes that they can deliver their project faster. The article goes on to state that, while speed is a possible outcome of agile methods, it is not guaranteed. Agile projects are more likely to achieve other benefits first, such as reduced technical risk, higher quality, greater likelihood of meeting true requirements, and more. Yet there are still those elusive speed-related benefits that people strive to achieve in their first agile projects.

To truly deliver software faster, one must look towards cutting down the timespan of all processes in the software development lifecycle from requirements gathering to deployment. Many who seek faster delivery use agile methods to improve the requirements gathering, design and development processes but are frustrated in their attempts to get a speedier deployment of the new software. These people often see deployment activities as unnecessarily cumbersome and often without much perceived value.

Perhaps the agile community has contributed to this perception. We have talked about concepts such as “continuous deployment” for years as if it were just one of the many agile techniques we can employ on our projects. Yet, this particular technique stands apart from many of the other basic agile techniques such as holding daily stand-up meetings, managing requirements using backlogs, and breaking a project down into iterations which culminate in a demonstration to stakeholders. Continuous deployment is among the most difficult of agile techniques to employ successfully and requires a very high level of agile maturity and discipline in the team.

When asking people why they want to use agile delivery methods, one of the most common reasons I hear is that they want to “deliver faster.” It seems that there is a widespread frustration with the way administrative bureaucracy, inefficient development processes, and overburdening governance processes impede project performance. In many cases, an apparently simple, short development project cannot be delivered quickly because of the process and governance overheads that stretch the project out across the calendar and act as a multiplier on the estimated project budget.

Of course project sponsors are frustrated with this situation – I’d be frustrated too. If there is needless red tape slowing down a project, that is an evil that should be rooted out and eradicated within our organizations. The problem, however, is that agile methods are not about delivering faster; rather, their benefits are in other areas:

At a recent workshop I was going over the Work Breakdown Structure and the need break the scope down into more manageable packages. One of the attendees had a question about one of his projects. He was managing a small project that was upgrading some instrumentation at four separate locations. The design work was supposed to be the same at all four locations. When he got the project it was bundled into one package. The question was, since the work was the same, it did not appear to be any big deal to have one package so, was it necessary to break something like that up into work packages? My suggestion was to break the work down into four separate packages for the following reason: Budgets Cost control Construction Budgets