now browsing by author


Project Manager as an Asset Not Taskmaster

Several months ago I participated in a lecture panel discussion at the Carnegie Mellon University’s School of Design.

My role on the panel was to bring a project manager’s perspective on design projects, specifically for development of software applications in the healthcare sector. One of the key messages I shared with the graduate students was to treat their project manager as an asset or resource, not as a taskmaster.

Rightly or wrongly, people often think of project managers as the “person in charge”. They see this indvidual as juggling timelines, schedules and checklists, and handing out task assignments. However, I wanted the graduate students from the School of Design to understand that their job would be easier if they treat their project manager as a partner and a resource.

In my opinion, a good project manager helps his or her team remove roadblocks and open new paths to help the team members achieve their goals. For example, if a software developer needs a new software license or a certain piece of hardware, their project manager should be the one championing the procurement of the new resources. Or if the UX design team needs to obtain feedback from certain customers, salespeople, or product users, the project manager could make those initial introductions and assist the designers to gain access to key stakeholder groups.

What if the business analysts and designers wanted to know the current set of feature priorities or the worst-offender bugs? How about what the latest data teaches us about a new product feature? The project manager should be able to provide the data or at least connect the analysts and designers with the right people who have the data.

It is our jobs as project managers to shield our teams from as much administrivia and unnecessary distractions as possible. This will allow your team members to do their best and most meaningful work.

I encourage project managers to inform your teams that they should treat you as an asset and not a task master.

3 Most Common Mistakes to Avoid in Managing Multiple Projects

Ever found yourself in a state where you are managing multiple projects? If you compare your situation today from about three to five years ago, the chances are that you will see more projects on your plate that need to get done.

A project can be anything, from designing a coffee machine for your client to remodeling their workspaces or even to studying ocean currents. The bottom line is that project management is an integral part of every business today. And, when you are handling multiple projects, it means more than just dealing with multiple project schedules. With multiple projects come in multiple teams, multiple stakeholders, multiple scopes, multiple change requests, multiple budgets, multiple issues, and risks, even possibly multiple clients. All of this becomes an entirely different ball game and managing it may seem a tough nut to crack, even for the most seasoned project and program managers. Even though you may already be using a project management software, you must always steer clear of these three common mistakes that could affect and potentially jeopardize your projects.

Not Setting Project Goals Upfront

Projects, by definition, are meant to achieve specific goals and objectives. By defining clear and precise goals and objectives for your projects, your teams can focus solely on those goals and outcomes. If the goals are unclear, it can quickly turn your formal project management process into an uncontrollable juggernaut of chaos coming in the form of scope creep, unrealistic expectations from stakeholders, dried up cash flows and all that jazz. Goal setting is a vital component for projects’ success. Yet, when multiple projects come in, managers often seem to take a shortcut and overlook this crucial process of goal setting that can potentially prevent and solve so many problems down the line. Setting project goals upfront help you in the following areas:

  • Understanding why you are doing this project and aligning it to business strategy and plan.
  • Understanding the deliverables that the management or client is expecting from the project.
  • Establishing clear criteria for success (or failure).
  • Identifying conflicting objectives, outcomes or expectations from multiple projects.
  • Identifying resources and capabilities at the beginning.

Asking the right questions at the onset of a project will help you identify meaningful project goals and objectives, which in turn help manage multiple projects successfully.

Not Prioritizing Projects

Manage your priorities, not your time. This quote frequently appears in many productivity and time management blogs. One of the most commonly heard complaints from project managers is that they are struggling with deadlines. The reason being too many times we see teams working on a project that is a lower priority while a higher visibility project starts to slip. This happens when project priorities are not clearly communicated to all stakeholders. When you are managing multiple projects, you often have cross-functional teams working on several tasks across these projects at the same time. If you don’t know what your priorities are, you will end up spending their precious time on useless activities causing important milestones to be missed and deadlines not be met. According to the Pareto Principle, 20% of a project’s input is responsible for 80% of its results. Use this principle as a way to prioritize your efforts. The art of prioritization comes a long way in gaining clarity about which tasks should be assigned to whom thereby help save a lot of hassle and headache.

Forgetting that it’s all about People Management

We live in a world which is increasingly being driven by automation, tools, and data. With organizations investing in advanced project management tools and globalization driving a need for collaboration, the people side of project management does tend to get ignored more often than not. Often while managing multiple projects, project managers tend to get bogged down by the scope, costs, quality, and timelines, and forget about the people who are actually doing the work. This results in either failing to properly manage your team members, or worst, micromanaging them. While it may be tempting to control as many things as possible or trying to do everything yourself, it is actually bad for your team’s morale. Project management is all about people management first. It is the people who help deliver on your project objectives and outcomes. An efficient project manager is, therefore, an enabler. Communication becomes even more crucial while managing multiple projects. You need to make sure that you clearly communicate the roles and responsibilities, and everyone understands how and why their part is vital to the success of the projects and also schedule time for periodic check-ins.

Though managing multiple projects may scare you off at first, you can easily overcome it by avoiding these common mistakes and steering your projects to success.

Don’t YOU be the Cause of an IT Project Failure

I have never had a project that I was personally in charge of fail from 1969 to present. The average failure rate for new projects is 14% according to CIO magazine .

The article covered most things that can be done to avoid failure. However, they missed one major cause of failure. I witnessed three projects, each 15 years apart that failed due to the same cause – one IT management decision. A project can have only one primary goal . They changed the project goal from solving a business problem to implementing their own favorite technical or methodological solution. The costs were huge. Two could actually be measured.

These were small projects, hardly noticeable, but with a large impact. All three projects started by coding a proof-of-concept and user demo with live data. Time was included in the plan for adjustments based on user feedback and completion of the final project from the proof-of-concept. Management stepped in after the demo and transferred them to another team with instructions to rewrite the app. All three projects might have been salvaged if they had just discussed lessons learned with the prior team as highlighted by point #7 in my article “Innovation and Turmoil ” (Ask for help or advice. Ask an expert if there is one.).

Coding Methodology (most recent)

The main goal for the team was to add security to the prototype and present the app at a convention. The core structure they started with worked perfectly (one company said that it could not be done at all). The team argued constantly about how it was written, was unable to meet the convention deadline and quit without writing the security module. The security module itself would have been a partial success and could have been written however they wanted. The app had the potential to save many millions of dollars in medical research but never made it to market.

Platform (15 years ago)

The app was actually rewritten without looking at the prototype and put into production. Our company had 700 consultants on the customer’s site. The cost overrun was so large and implementation date was missed so badly that the customer VP was reprimanded in his review by the president for failing to kill it early on. After that, the customer, per contract, cut the maximum consultants on site (70) each year AND the consulting firm never received another new project. One consulting firm manager actually thought the app was a success in demonstrating object oriented technology.

Computer Language (30 years ago)

The new team was unable to complete the project at all. I would have had it in User Acceptance Test within 2 weeks of the demo, but management wanted it converted to PL/1, the language that they understood. The app was requested by the division’s largest outside customer, the largest car battery retailer in the US at the time. One year later, the company lost that battery contract.

Inadvertent Comments

This was not a project, but it is related. The machine converting powdered carbon to pellets was leaking dust. The Senior VP was touring our plant. He said “Tighten up those seals.” The machine ground up the seals into the pellets. We had to scrap 12 million dollars of product. Luckily, our database was able to isolate by lot number the product produced by that production line from the other 5 lines. That one statement cost the company 12 million in profit that year.

None of the managers involved in the examples ever knew how much damage they did to their company or their customers. It is very easy to destroy a project by repeating history. Don’t confuse project outcomes with business outcomes . Always be careful what you say, pay attention to the small projects, and never forget the business goal.

Closing a Project: What, When and How

Projects, by nature, are to be closed. I am sure you know this. The two authorities made this obvious in their definitions of what project is.

Take a moment to review the definitions from PMI and AXELOS.

A project is a TEMPORARY endeavor undertaken to create a unique product, service or result. (PMBoK Guide 6th Edition)

The above is the definition of a project by PMI (Project Management Institute), an organization founded in 1969, with headquarters in the USA and who has been providing guides, standards, and certifications, amongst other things, on project management since its inception. The key word is that definition is TEMPORARY, which literally means must have a start and end time.

Let’s move over a minute and take a look at the definition of a project from another body.

A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case (Managing Successful Projects with PRINCE2, AXELOS)

One thing is common to the two definitions. Did you see it? Yes. It’s the word TEMPORARY. A project is temporary and must be closed. Don’t confuse the term TEMPORARY with SHORT. I have got few of this concern from some of the students I train. A project can be for between 1 month and 36 months. It just means it must start and end at a particular date

Now, let me take you through the WHAT, WHEN AND HOW of closing a Project.

Note: I will not discuss whether the project is successful or failed.

WHAT is Closing A Project?

It’s has been established that every project has a start date and an end date. So, the process of completing the work on the project to an end is exactly what closing a project is. Nothing more, nothing less. If you are not closing an exercise or ending an exercise, then you need to know that the exercise isn’t a project.

It could be an operation. One of the differences between a project and an operation is that while projects are temporary, operations are ongoing and continuous. No matter how long the duration of a project is, it must end.

WHEN do you CLOSE a Project

Well, there are three circumstances under which a project can be closed. Yeah, THREE! One out of every ten readers of this article will find this surprising. Just give me a second and I will explain the three times.

  1. When the project has delivered all the objectives and/or RESULT.

This is probably the most popular and most desirous time when a project should be closed. At the beginning of the project, a set of objectives, deliverables, and results were set. The PM and the whole organization rolled up their sleeves and started working towards building and delivering the objectives and deliverables for the project. Once the objective is met and the deliverables completed and accepted by the Project Sponsor/owner, it is time to close the project. Reason? The PM and the team have completed all they committed to, and there isn’t anything left to do on the project. What if there is a modification or an addition to the deliverables of the project. Well, that’s called scope creep, if there is no adjustment to other components that may be affected, and once the addition didn’t go through change control for approval, and no re-baseline, then it has to be initiated as a new project, after closing the current project.

For PRINCE2, Once the project has delivered what was specified in the business case of the project mandate, while for PMI, once it has developed the content of the approved scope.

  1. When the objectives of the project can’t be met again

This is often called TERMINATION. Hopefully, it can be done early.

This is usually not a very pleasant one, but it’s usually a reality. It could be as a result of the complexity of the project or a combination of many other things. I recall working on a project with some client in the financial services industry a few years back. The business case and feasibility were highly optimistic and the organization decided to invest in the project hoping for the objective to be realized. However, after series of attempts, efforts, and re-baselining by the project team and the stakeholder, it became clear to even the blind stranger that the approach and the technology chosen for the project couldn’t meet the objective, the organization had to terminate the project for that same reason.

At times it could be that the organization had spent so much money on the project, yet they haven’t realized any benefit and at every point in time, there was no sign that the project would still deliver the objective.
Please note that in most cases, the project manager and the team are not responsible for this, and often should not be blamed.

3. When the objective of the project is no longer needed

This is often called early termination

We live in a dynamic and constantly changing environment, and there are many actors and factors driving the market and corporate space. Most of these factors could be a technological change, a governmental policy, a change in strategy and direction for the organization etc. PRINCE2 advises that at every point on the project, the project organization should continually check for business justification, to ensure the business case is still valid. If at any point the organization realizes that the business case has become invalid, the only thing left is to close the project. A typical example was a project I was working on for a client to penetrate a new market and release a product that would solve a particular challenge. We were about 45% into the project when the government introduced an initiative that would address a similar challenge at no cost. It became obvious that the product would not make many sales, hence the objective and business case became invalid. We had to terminate the project immediately. This is better than going head to complete the project. Organizations don’t just initiate or complete a project for the mere sake of completing a project, the product of the project must be valid all through and the end product must be desired and desirable at all time.

Another example was a consulting project I was working on with a startup to rebrand the company. Midway into the project, there was a merger and acquisition with another company it became instantly known that there was no need to rebrand the company anymore. Again, this could be at no fault of the project team.

In the next section, I would highlight how to close a project, irrespective of when it is closed.

HOW to close a Project

No matter when. You need to close the project. About three years ago, I worked on a research project with about twelve other professionals to review project management processes and health check of organizations within three continents, and we found out that a lot of organizations don’t close projects well, and this is quite worrisome. As they were completing one project, the team was being drafted to other projects or assignment without proper closure process. Hence the reason I decided to write this article.

This process will be broken that into two different sections. The first section will highlight steps to closing a project whose objectives have been met, while the second would highlight the steps to close a project whose objective is either not needed again, or can’t be met.

How to close a project whose objective has been met.

  1. Confirm that all the deliverables have been completed and accepted by the appropriate approving authority. Here you will need to reference your plan, specifically your approved scope and acceptance criteria
  2. Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
  3. Close any procurement component of the project
  4. Gather the team and update lessons learned on the project
  5. Release all resources and provide feedback as required
  6. Complete end of project report and archive project information
  7. Celebrate. And I mean it.

How to close a project whose objective can’t be met or whose objective is not needed again

  1. Validate the reason for the early termination
  2. Determine all the deliverables that have been created so far, and ensure they are accepted
  3. Obtain formal closure notification from the Sponsor
  4. Close any procurement engagement
  5. Update lessons learned with the team
  6. Release resources and complete end of project report, capturing the stage the project was at when it was closed, the reason it was closed and the lessons learned and archive project information.
  7. Celebrate (if you have the courage to)

Is the PMO Necessary for Project Success?

The project management office – or PMO – is generally considered the proper project management infrastructure for project-centric organizations.

Does your organization run and manage individual projects to get internal and external customers work done? Or do they just assign people to develop software and work with clients in planning, risk and issue management? If they run mostly projects than you likely have – or should have – a centrally focused and managed project office. Why? Well, to know that let’s discuss the major benefits that such a project-centric focus can bring to the organization and the customers it serves…

Consistent delivery.

Having a central project office or PMO allows an organization to staff and plan work for experienced project managers who are trained to effectively and efficiently lead projects, manage financials, lead skilled project teams and the customers they serve. The PMO guarantees the PM focus. Without that infrastructure, it’s difficult to justify putting a PM team together not knowing what type of utilization those resources will actually have.

Consistent and repeatable project successes.

Having skilled project team members ready and a trained pool of experienced projects managers available helps organizations to better serve their project clients. Having the tools and templates those team members and project leaders need available for every project helps increase the likelihood of ongoing project successes on a consistent basis rather than just succeeding on projects based on luck. Everyone will take a little luck now and then, but consistent project success comes from an experienced staff and defined, repeatable processes and re-useable tools and templates.

Budget management.

Rather than just running projects or doing work, with the PMO in place the project managers will be performing better project budget management by utilizing structured processes for estimating, tracking, analyzing, forecasting and re-forecasting project financials. Watching them closely on a weekly basis and getting accurate updates from accounting for actual project expenses means they can stay aware and keep potential project budget overruns in check. Watching and re-forecasting weekly means project budgets will likely never go more than 10% over plan – a very fixable number. Left unchecked, it’s so easy to end up with a 50%+ budget overrun without realizing – a hole that is nearly impossible to dig yourself out of.

More effective use of project support resources.

With the project office, project resources will be tracked better and utilized more efficiently. How? Through proper tracking, utilizing a recognized pool of skilled project resources with the right tool set and a gate-keeper process of requesting and getting the right mix of talent added to your project team. When projects or work is done in a non-PMO environment, resources are not generally considered assignable from a skill set standpoint like in a professional services matrix type resource environment that is focused on a project-centric delivery organization. The PMO brings structure to that process and helps make each project team the best it can be at any given moment and the right fit for the project and project customer.

Improved financial performance for the organization.

From the always critical financial performance standpoint, the PMO will bring improved financial performance to the organization. Project finances are considered on a project by project basis as well as across the portfolio of projects, and structured processes are generally in place to ensure budgets, budget health, and overall financial performance is a key factor in all project status considerations. It’s not just about getting the work done as can be the case in organizations that are just performing work on an as needed or requested basis without planned tools in place. It’s about managing each project right from the outset – including planning and financial oversight utilizing consistent tools, delivery and status reporting ensuring that each project budget never gets too far out of hand no matter what issues arise.

Continued organizational growth.

With a structured PMO, the organization has a better chance to achieve continued organizational growth. Why? Because a structured PMO will allow the organization to better plan for customer projects and have staff available and ready to assign to project work. In the non-PMO environment, work is often promised to customers based more on financial need and customer need without also considering “can we deliver?” and “do we have the right staff available at this time to deliver?” Too often resource shortages come up when critical work needs to be done because the non-PMO environment makes it much more difficult to look at and consider the entire landscape of resource needs and availability to successfully deliver on the projects you are lining when the customer needs those projects completed. It’s an awkward situation to walk into when you must explain to a customer that you just don’t have the right resources available at this time even though they are expecting you to start delivering on a $650,000 technical project. Oops.

Better career leadership growth to serve projects, the customer and the organization.

The PMO is usually in place for several reasons – the #1 reason being to enable the organization to more consistently deliver successful projects to the customer that are also profitable to the company. But another key consideration is acquiring and nurturing a skilled staff of project delivery personnel and included in that is the planning for training and career growth for each of those individuals. In the non-PMO environment, project leaders and team personnel may be just warm bodies available at that moment to take on the next customer engagement. The PMO plans for this and makes sure that the resources are skilled and continue to grow those skills allowing the organization to take on new and different projects resulting in increased revenue in new technical and project delivery niches because the staff is continually growing in skill set and delivery ability.

Summary / call for input

The bottom line for me anyway is that yes, the organized PMO approach is necessary for project successes on a regular basis in the organization. What your important customers will see is an organized and professional effort – every time out – to deliver expertly on each of the project engagements. And that’s huge – that’s what project management is all about, right?

Readers – what is your reaction to this list? Please share your ideas.