Skip to main content

Navigation

Poll

Would you be interested in an IPMA Project Management Consultant certification for Canadian PM trainers and advisors?
Yes - Let's see the details!
60%
No - Don't think it would be of value
3%
Not sure - Need more details before making up my mind
37%
Total votes: 105

Who's online

There are currently 0 users and 28 guests online.
Home

Articles

“Oh, By The Way..........."

April 30, 2013 by morley

morley's picture

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

Thinking on Purpose for Project Managers

December 4, 2012 by Anonymous

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

November 14, 2012 by pmacwebmaster

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.

Continuous Delivery: The Ultimate Challenge for Software Development Managers

November 13, 2012 by aguanno

aguanno's picture

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.

Agile Methods and the Need for Speed

November 9, 2012 by aguanno

aguanno's picture

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:

He Knows What He's Doing

April 9, 2012 by morley

morley's picture

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

SAFETY HAS A COST

March 13, 2011 by morley

morley's picture

WHAT ARE THE SAFETY COSTS?
Think of your current job. If you got injured, became ill, or died what would be the affect on those around you and your company? What would be the cost? Well, here are some of those costs:

- Training cost of replacements. Think of having to replace someone with experience. The training can be done but the interpersonal relationships cannot be replaced. You will never get back to where you were as it difficult to replace the experience. If it is advanced knowledge you are replacing it can be very expensive to train someone.

- Damage to equipment, property, or products. As in the above example, the cost of equiment replacement can be expensive. If the accident did not happen, the money would have gone to improving the value of the plant. The cost of repairs may be covered by insurance but the increased premiums takes away money from adding value to the plant or product.

Project Management Advice from Popular Music

March 2, 2011 by aguanno

aguanno's picture

I was sitting in a project team meeting yesterday where a group of us were trying to figure out the right strategy for dealing with a difficult project sponsor. The issue was that the scope of the project was constantly changing and we were being rebuffed by the sponsor when we tried to point out that our requirements gathering and analysis budget was already spent, yet new requirements were popping up daily. The sponsor was saying that they need all of their requirements documented and the impacts on the solution design analyzed – which is correct; however, the sponsor is not willing to reallocate funds from the solution build budget to the requirements budget, nor is he willing to discuss adding funds to the project overall budget.

Handling Difficult Conversations

February 2, 2011 by pmacwebmaster

As Project Managers we often find ourselves needing to handle difficult conversations in order to make progress on a project. These meetings will happen with direct reports on a project team but also with other stakeholders who we have no direct authority over but are critical to the project success. How often do we plan effectively for any of these meetings, not just data and information, but around how we are going to handle the meeting and the people attending it?

There are a number of ways we can improve the way we handle our difficult and challenging conversations to make them more effective, improving individual and team productivity and our business relationships.

Testing Strategy is Critical to Project Success

January 31, 2011 by aguanno

aguanno's picture

I once heard the president of a large company say that sales people were important because they increased the revenues of the company but that project managers were more important because they turned those revenues into profits. And those profits, he noted, drive an increased share price (the value of the company in the marketplace).

If we as project managers are responsible for the creation of a company’s value, then we have a professional obligation to perform that job well, as the converse would also be true: project managers performing poorly can also destroy a company’s value. How do we perform our job well? To answer this, we need to look at which project management activities have the greatest impact on achieving the project’s desired outcome, as valued in the business case.

Premium Drupal Themes by Adaptivethemes