Posts Tagged ‘project’

New Release of Project Administrator project management software

Monday, January 20th, 2014

We have just released version 7 of our Project Administrator project management software. The main changes are:

  • Improved navigation with most screens being changed to make moving between records easier
  • Ability to link any action item to a meeting item
  • Enhanced PDF functionality for emailed reports
  • Minor changes to the 64 bit functionality to remove a few bugs we discovered recently

For those who have not used PA in the past, there is a 30 day fully featured trial version available.  If you decide to buy, a single user license only costs Australian $50 which is about US$44.

Project Administrator manages issues, risks, actions, meetings, schedules, roles and responsibilities, budget and expenditure, checklists, timesheets, diary notes and even a glossary.

To download a trial version Click here

To read more about Project Administrator Click here

My Project Is Not Failing

Wednesday, March 27th, 2013

Maybe we are all reluctant to accept that our project might be failing but with high project failure rates in many industry sectors we should make sure we are able to spot the main warning signs. And then act on them rather bury our heads in the sand and hope it will “be alright on the night”. That approach will never lead to a successful project or a successful career in project management.

Just because things might not be going to plan doesn’t mean a project is doomed – managing problems and risks is all part and parcel of a project manager’s role and a risk management plan should be in place that will help to mitigate the very risks that might be causing problems. If a risk plan has not been prepared, don’t worry it is rarely too late to review the real and potential risks that might be threatening your project and to deal with them effectively. Problems that materialise in a project, whether expected or not, are inevitable in many industries and with a controlled approach they can usually be mitigated.

The very fact that problems so often arise in IT projects, for instance, is what led, at the beginning of this century, to the creation of the Agile Manifesto, with its values and principles designed to help project managers work constructively to solve problems rather than either being defeated by them or trying to ignore them. An agile approach recognises that many projects are simply unsuited to the traditional “waterfall” approach and offers an alternative where deliveries are made in small stages allowing for user feedback to be incorporated into the next stage. Increasingly both waterfall and agile methods are recognised as appropriate for different types of projects and in some cases they are being combined on a single project.  All projects have their ups and downs so it is important to remain optimistic in the low periods and remember that things will change.

It is reassuring that the formalisation of project management methodologies over the past 20 years has led to a significant improvement in project success rates. Increased used of the internet has also helped by making status reports quickly and easily available so that problems don’t drag on undetected for too long.

 So what are the warning signs of a project that could be destined for failure? If your know how to spot these and act on them you already have the means to turn a potential disaster into a success. Warning signs of pending trouble are usually relatively easy to spot – here are some typical ones:

 1.      Lack of Buy-In

When those working on a project have been pressured into becoming involved they will never be fully committed to its success and will not give 100% of their time or energy to the project.

2.      Poor Communication

Communication takes many forms; there are the informal team discussions, regular meetings, emails, phone calls and various written reports and other documentation. If any of these areas are lacking then there is likely to be a problem looming.

3.      No Visible Progress

If it is not possible to see what has been achieved to date then it is difficult to convince stakeholders and the team that success is possible. A lack of visible progress (or “velocity” in Agile project management) is de-moralising for everyone involved.

4.      Long Hours

If the project team are having to put in long hours just to stay on top of the scheduled activities then this is a classic indicator that all is not well. Either the original estimates were badly wrong or the scale and scope of the work was not clear.

5.      Milestones Missed

Milestones should deliver manageable chunks of work to the customer on a frequent basis. If this is not being done, or the deliverables cannot be tested by the customer, there is no opportunity to get feedback for the next phase to know the project is on the right track.

6.      Changing Scope

Every project’s nightmare is scope creep – adding to the requirements during the project – it is usually an indication that requirements were not fully documented or the customer did not understand the aim of the project. But often a more serious warning sign is when features are being removed from scope and the end-product is being scaled back.

Remember that warning signs such as these give you the opportunity to rescue a project from failure so should not be ignored but treated as part of the project management process. By looking out for warning signs and using your experience and personal skills (supplemented with the right project management courses) a project manager can avoid project failure.

Author: Michelle Symonds

Lessons on the Wrong Resource

Tuesday, April 3rd, 2012

Here is a lesson I learned when doing a project review.  I guess I knew it all along but it was certainly brought home to me when I did the review.

A large public corporation had just finished a project.  It had been difficult to say the least.  It was well over budget and time.  The deliverables were not in line with the original scope statement and there was already talk of a “Stage Two”.  The project had been particularly political and I was brought in as an independent person to review the project and identify any lessons learned.

In preliminary discussions it was hinted strongly that the problem was the project manager.  He had not taken control of the project, and many things had not been done properly.  He set adventurous deadlines and did not manage the business staff well.  I kept an open mind but there was certainly a perception that the project manager was to blame.

I reviewed the project documentation before starting interviews and it did appear weak.  The risk assessment was only done once, and appeared superficial.  There was little follow up on mitigation strategies.  There was no documented process for managing variations.  The schedule updates seemed to be sporadic.  There was no Project Plan.  Some of the content you would expect to find in a project plan was scattered through a number of other documents and some just missing.  It was evident from the documentation project management was weak.

I interviewed the project manager and he was very defensive.  He pointed the finger at many people who had contributed to the problems.  He claimed lack of support, and lack of authority.  Decisions were taken without his knowledge and he was later informed.  One example was a major variation that was agreed without him being aware of the proposal.  He was told to just go do it.  Clearly he was not in control.

As we proceeded, I asked about his previous experience.  I was astonished to find that he had never undertaken a project this big.  In fact his biggest project would barely be a tenth the size of this project.  I asked him how it was that he came to run the project.  His answer was that it had been presented to him as a chance to prove his worth.  An opportunity to show people what he could do.  The break he had been looking for to advance his career.  He had no formal training.  He had carried out a few small projects but never been trained in project management.

Once I knew this, I could understand his perspective.  He found:

  • People were not cooperating as he expected them to
  • Verbal assurances were never honoured
  • Decisions of a critical nature were not being made with his input
  • The staff he was given were not up to the job requirements
  • The original estimates he was given were not realistic

The worse it got, the more he found people finding a way around him to run their own agenda.  He was not only out of his depth.  He was set up to fail.

So where did the blame lie?  Most people, including myself, have taken on a task and found it was much more complex than we imagined.  In some cases we have taken it on because we pushed to be there, and in other cases we were pushed into the situation.  In the former case , we may be able to lay some blame at the feet of the person who gave in to our demands to allow us to carry out the task but mostly, we have ourselves to blame.  In the latter case, the main person to blame is the person who pushed us into the situation then set us adrift.  The project manager was definitely the latter case.  He was pushed into the role, his reservations were smoothed over, and then he was set adrift.

My report identified this as the problem, and the person who was Sponsor was the person responsible.  What I couldn’t say in the report, much less prove, was that the poor guy was appointed because the Sponsor wanted someone he could dominate and who would not stand up to him over project issues.  I recommended the project manager be given proper training and continue working in that role but on smaller projects until he built up his experience.

A year later I had coffee with a person from the corporation and asked what had happened.  Unfortunately there was no fairy tale ending.  The project manager had resigned, or been forced to resign.  It was not clear.  The Sponsor had rubbished my report and said I would never work for them again.  Stage two of the project had been outsourced and was now causing bitter disputes within the organisation.

I did work for them again.  After about three years, the Sponsor had moved on, and I was approached to do some more work for the corporation.  Evidently someone had said to the CEO that they needed someone who would “tell it as it is” and I had proved I would three years previously.

The lesson to come from all this is that you need the right resources.  In this case it was the project manager but I have seen the same situation in every project role.  Not putting in place the right person will come back to bite the project somewhere down the track.  The other lesson is to make sure that you have the capability to do the job when it is offered to you.  There is an old saying “beware of Greeks bearing gifts”.  I think it refers to Trojan horses, but in the world of the GFC, it is just as appropriate today.

Lesson on Identifying the Outcome and the Problem.

Monday, March 12th, 2012

What is the problem the project is trying to solve?  Think about your current project.  Can you answer that question?  Why is it even important?

Every project is trying to solve a problem.  The problem may be:

  • We cannot cross a river
  • There is an opportunity to claim a niche market
  • Our software is no longer supported

If the problem is identified, the outcome can be identified.  It is not the solution.  There is a difference.  Taking the first example, the outcome is that we need to cross the river.  The solution may be a tunnel, a bridge or a ferry.  We might select a bridge as the solution, but it may not necessarily be the only or even best solution.  A business case needs to be developed to look at how we can achieve our outcome and nominate the most suitable solution.

Too many people focus on the solution rather than the outcome. In the second example we might say let’s build a new product to meet a niche market.  Perhaps the solution could be to have someone else build the product, or to patent the solution and sell the patent.

This particular lesson came from a review of a project in crisis.  A stockbroking firm were building a new client information and transaction system.  They had employed a company to build a web based solution.  There had been numerous prototypes built but they could not settle on the final product.  The CIO called me in to try and resolve the situation.  My assignment was to last a week.  I was gone in two days – very poor form for a consultant.  This is how it happened.

My first interview was with The Financial Manager.  They were providing the funding and were co-sponsors of the project.  I asked what outcome they were trying to achieve.  The response was that they were trying to provide better customer service and retain their client base.  In fact I think they were trying to keep up with their competitors rather than surpass them.  In order to do this for the minimum cost, as things were tight financially, the solution was to develop a simple interface that allowed customers to undertake basic transactions and see core information.

My next interview was with the other co-sponsor, the Marketing Director.  I started by asking the same question.  His outcome was a bit broader than the Financial Manager.  He also wanted to provide better customer service but also wanted to attract new customers from his competitors.  In order to do this, his solution was to build the best, most sophisticated customer interface in the industry.

In the afternoon I spoke to the company building the system.  It took a while to get to the truth but the crux of it was they built prototype A and showed it to the Marketing Director.  Add more bells and whistles said the Marketing Director.  They did and showed prototype B to the Financial Manager.  Take out the bells and whistles said the Financial Manager.  We can’t afford them.  Back and forward they went from one to the other adding and removing features.  It was a bit more subtle than how I explained it but the software developer was happy.  They were being paid by the day so variations were all paying work.

By the end of the first day I went back to the CEO and said this.

“The problem may be that you risk loosing existing customers.  In this case the outcome may be to improve services to existing customers.  The problem may also be that you need additional customers to build the business.  One solution may be to attract customers away from your competitors by offering more attractive services.  Both have a potentially different solution so until you decide the problem and outcome, you cannot set the path forward. “

Day two started with a meeting between the CEO, Financial Manager and Marketing Director.  The two co-sponsors explained their perceived problems and desired outcome independently.  There was considerable discussion on which problem was relevant, and it was decided that for this project, we only wanted to look at the problem relating to retaining existing customers.  We then matched where the outcomes were the same and highlighted where the outcomes were different.  Different included outcomes where only one of the co-sponsors had a desired outcome.  It took several hours of debate, and a few directions from the CEO before they had an agreed, common outcome.  That outcome did not include stealing customers from their competitors.  We then worked on the best solution, and by lunch time we had an agreed solution which formed the scope of the work required.  We invited the development team in, and matched their work to the scope statement.  By the end of the day, a conceptual prototype was agreed.  It was in fact a stripped down version of the most recent prototype.

Ready to go home at the end of the second day, I was drawn aside by the Marketing Director.  He asked “If we have another project, and the outcome is to attract our competitor’s customers, what would be the solution?”  I had to point out that there were many solutions.  He had to identify the solutions and evaluate which of those had the best business case.  It may be to enhance the basic customer information system or it may be a new product to attract those investors.  I think the lights finally came on.  He got it.

I did hear from him a few months later when he asked me to facilitate a meeting of his key managers.

“We want to talk about outcomes” he said.  “I want my team to brainstorm solutions and then we can go away and develop business cases for them.”

I asked him how the new customer information system was going.  It was in place, and getting good feedback from the existing clients.  He said he couldn’t understand how it had taken so long to get started.  Sometimes you think you have broken through and then the person confirms there is still some way to go.

Lesson on Managing Variations

Wednesday, March 7th, 2012

A lesson I learned many years ago from a very experienced project manager related to managing the changes in a project.

The project was nearing completion but was over budget and over time.  I was not managing the project.  It was being managed by a colleague from the same company I was working with at the time.  He was asked to attend a board meeting to discuss the project.  He suspected it was an ambush.  The CEO was going to try and put the blame on the project manager and possibly fire him.

The project manager seemed unconcerned.  He told me that it was all under control and no action would be taken against him by the board.  I did not understand his proposed defence but he was adamant that he could convince the board of the quality of his project management.  He was one of the best project managers I had ever encountered so asked what my role would be.


The meeting unfolded as expected.  The CEO spent some time outlining the cost and time overruns.  He detailed how the board had approved the appointment of the project manager but the project had now run out of control.  As CEO he pointed out he had many responsibilities and had not had the time to become intimately involved in every detail.  He had sought reassurance from the steering committee that in spite of what had seemed warning signs, all was well.  They had assured him it was.  Finally he had heeded those warning signs, stepped in and found the situation worse than expected.  The budget to complete the project was some 50% over, and it was running several months late.  Our company should be called to account and made to share the cost of the failing project.

There was one board member who knew the project manager well from a previous engagement.  He had in fact recommended this person lead the project.  During the tirade by the CEO, the board member was looking curiously at the project manager as if to say

“Aren’t you going to defend your actions?  Surely this cannot be true.”

I must admit I was feeling uncomfortable but the project manager looked calm and relaxed.  Finally he was asked to respond.  The response went something like this.

“You guys run a tough company.  It is hard to get recognition for a success.  Yes we are 50% over the original budget and yes we are three months over the original schedule.  If you look at the papers I have here you will see that every variation has been estimated in time and cost, and approved by the Steering Committee and CEO.  In fact if you add them all up, you will see we have added 60% to the original budget in terms of cost, and four months to the schedule.  I am actually under the revised budget, and ahead on delivery.

I also have a file of rejected variations that would have put the project another 50% over budget.  Every change is costed, evaluated, considered by the steering committee and approved or rejected.  Nothing that will impact the original scope is undertaken without approval.”

He sat down.  To say there was silence would be an understatement.  It was beyond silence.  It lasted about a minute.  The only sound was the wheels turning in the head of the CEO as he tried vainly to find a way to dig himself out of the hole.

Finally the friendly board member spoke.  He said to the CEO.

“So how is it you were not aware of the cumulative impact of the changes?”

Much stuttering and stammering followed.  In the end the project manager was congratulated by the board for the process and control he brought to the project.  The CEO was reprimanded for wasting the time of the board, and not being across details he should have known.

The lesson I took away from this was that every variation needs to be quantified and submitted for approval.  More importantly there needs to be a strict process in place for this to happen.  It is always easy for the project manager to say yes.  Nobody will thank you for saying yes when the fan takes on a brownish hue.

Lesson on Managing Issues

Tuesday, February 28th, 2012

Here is another lesson I learned from a real life project.  This one relates to managing issues.  On one occasion I was called in to look at a struggling project.  The project had about 100 staff but seemed to be going around in circles.  Progress had slowed if not stopped.

The first task was to get to grips with why.  The problem turned out to be many problems.  Almost every aspect of the project was bogged down in problems that were causing the wheels to grind to a halt.

The project was to implement SAP in a manufacturing organisation.  The team doing the data conversion were waiting on the team doing the database design before they could proceed with the conversion testing.  The team doing database design were waiting on feedback from SAP in Germany regarding some customisation before they could finalise their design.  The team in Germany were waiting on input from the manufacturing as to how they wanted to handle component specifications.  This was just one example.

All the problems had been raised as issues and were being considered but had been delayed because everyone seemed to be reliant on someone else making a decision.  Schedules were constantly being revised.  Just getting all the relevant people into a room seemed impossible.  A sub group would write up a proposal which would be circulated for agreement, and usually the proposal would not work for another sub group.  Decisions were taking weeks.

The problem was there was too much activity and not enough action.  My proposal was to stop the project for two weeks and solve all the problems.  The typical response was:

“We can’t stop the project.  We are too far behind now!”

Finally sense prevailed.  We actually identified about 30 major issues.  Some were related to others and some unrelated.  For each issue we identified the core problem.  Where did it all start?  What was the thing we needed to solve to enable subsequent decisions to be made?

We treated the issue resolution as a project running two weeks.  By identifying the resources we needed to solve each issue, we were able to schedule multiple workshops and ensure everyone who needed to attend was present.  For those not participating in the exercise, we had them working in a support role.

  • When decisions were made they could work on the implementation of the decision.
  • They were involved in gathering information to allow the decisions to be made and tested.
  • Some work could proceed regardless of the issue roadblocks.

One problem we did encounter was the logistics of having enough meeting spaces.  Fortunately there was a nearby hotel that had conference facilities we could use.  We also had to involve people on the other side of the world in teleconferences so we basically ran workshops for 18 hours a day in some cases.

The workshops ran from half an hour to a few days.  Yes, one did get resolved in half an hour.  It was just a matter of getting the right people in the room at the same time.  Timing was unpredictable and we were constantly shuffling timings of meetings.  In fact we ended up publishing a new timetable twice a day.

All meetings were facilitated.  An independent person ran the meeting to focus the group and ensure all views were considered.  They were typically non experts who had nothing but common sense to contribute to a solution.  Because they were not experts they could ask the basic questions that sometimes removed the complication.  I remember one issue which related to catering for multiple overtime rates for different groups of people.  The differences were minor.  The facilitator asked if anyone had costed the expense of managing the rates versus the cost of a single rate.  Another group did the exercise and found it was cheaper to have a single rate at the higher level than lots of minor rates.

At the end of the first week, we were down to about ten significant issues.  Some people were able to get back to project work as roadblocks had been cleared.  After two weeks we were down to about two or three issues that were still being worked on.

What we learned was that sometimes it is best to stop.  If things are getting out of control remember the old adage.  When you have dug yourself into a hole, stop digging.  The project team had a much different view on resolving issues.  As the project proceeded, they gave much more importance to fixing problems.  If an issue came up, the Sponsor made sure everyone who was involved made themselves available to resolve the issue as soon as possible.  The Sponsor required all significant issues be escalated to him, and the impact of the issue on the project had to be stated as part of that escalation process.

Another lesson was that all experienced project managers know there should be a proper issue resolution and escalation process in place but business leaders may only pay lip service to such a process.  It is only when things start to go pear shaped that they see the value in the process.  Just because it is documented some where, does not mean it will be accepted or followed.  Occasionally a bit of pain is needed to teach people the value of a project process.

Lesson on Risk Management

Monday, February 6th, 2012

Having been in project management for many years, there are lots of examples of how applying the right approach has proven successful.  Here is one relating to risk management.

In a major company wide project to implement a new system, we spent several weeks doing the planning.  It was evident there were about six key personnel who would need to guide us through the configuration and customisation of the software.  We worked closely with them to develop the plan for the project.

During the planning we did a risk workshop.  An obvious risk was that over the 15 months the project would take, we might loose one or more of the six key participants.  As a mitigation action we decided that each of the six would have an understudy.  They would select a knowledgeable colleague and ensure they were across all relevant aspects of the project.  They would attend key meetings and participate in decision making activities.  It was an overhead in terms of cost and time but one we thought was worth doing.

A few months into the project, one key player announced she was pregnant.  She would be leaving the project at a critical stage.  Fortunately, because of our risk planning, we had a back up in place.  The girl later told me that she was in fact pregnant when appointed to the project but had decided not to make it public until the first trimester had passed as she had problems previously with pregnancies.  She said she was torn for a week between participation and revealing her pregnancy.  When we did the risk assessment she could see the damage caused by her leaving the project had been alleviated.  A weight had been lifted.  She focused on ensuring her understudy was fully prepared.

She did have further complications and a few months later had to give up full time work.  Fortunately the pregnancy went full term and she delivered a healthy baby.  The impact of her leaving the project was minimised.  We brought forward key decisions and these were made before she left, and her replacement carried on her work.

I have heard people say risk management is a waste of time.  The risks never eventuated.  It is only when a risk does eventuate that the value of the exercise is illustrated.  We have probably all seen the situation where the impact of a risk is minimised.  We should have the stories ready to roll out when we do strike opposition to a proper risk management program.  Experience is a great teacher.

Do Project Managers Need In-Depth Business or Industry Knowledge?

Friday, February 3rd, 2012

In order to be successful as a project manager it is questionable whether business knowledge is a help or a hindrance. Some organisations see it as a benefit but it can also prevent a project manager from seeing the “bigger picture” of a project.

Many people believe that for a project manager to be successful, they need to have not only good project management skills and experience but also previous experience of the business area or industry in which they are working. This view is probably so widespread because they have often, in the past, simply progressed from one role within an organisation into a project management role in the same company. Their previous experience is often seen as a bonus and they are just thrown in at the deep end of project management and have to quickly get up to speed with a relevant training course, or worse, no training at all.

But do project managers who have reached their current role in this way have any greater success than a formally trained professional? Or do they find it difficult to remove themselves from viewing the project at a detailed level because they understand the business in-depth but are then prevented from seeing the project from a wider perspective. It can actually be a disadvantage to get too involved in the detail of individual tasks and activities.

A professional project manager will have been trained in a wide range of skills that are transferable across businesses and will have built up enough practical experience to be able to gather the right amount of information about the business in order to understand the needs of the client. After all you wouldn’t expect other professionals such as lawyers or accountants to know everything about your business – they just need to understand enough to do their job properly.

It could be argued that there are some industries where detailed knowledge of that industry is a pre-requisite for a project manager and that may be the case in certain technical areas such as IT but it is not the case for the vast majority of projects being undertaken across a wide range of businesses. An understanding of building and motivating a team, planning and managing tasks, risk and change, and having the skills to interface effectively with a range of employees from senior managers and stakeholders right down to the most junior team member are far more important skills for a project manager to have.

So if you want to develop your career fully and have the confidence and freedom to move into new business areas, organisations or even industries then concentrate on developing your project management skills and don’t worry too much about your business or industry knowledge.

Ensure you have the confidence and ability to talk with business heads about defining the goals and objectives of a project, determining the expected benefits and the impact on the status quo, and where the project sits in terms of overall priority within the business. Assist with documenting the detailed business requirements and clearly describing the project by being an effective interface between the business heads and users and the project team who will deliver the end-product.

Then increase yours and the project team’s chance of success by ensuring you document who owns the project, who the stakeholders are and what criteria will define its success. And also ensure you establish a proper communication strategy and that you understand the reporting requirements.

Then you can actually get started with planning and running the project, assessing and managing the risks and establishing a solid change management process.

And, before you start, don’t forget to ensure that enough budget, time and people have been allocated so that the project is at least feasible at the outset.

When you consider all these project management skills that are required you wonder how a project manager would actually find the time to get closely involved with the detail of the tasks – even if he/she did have the relevant business knowledge. Far better to focus on developing yourself as a project professional and gaining transferable qualifications such as one of the APMP accreditations or a PMP Certification


5 Key Components of a Project That You Need to Get Right

Monday, January 30th, 2012

There are many factors that contribute to the final outcome of a project, whether it is large or small, simple or complex. But just a few of these factors will determine the ultimate success of your project.

Projects come in all shapes and sizes such as straightforward improvements to products or operations procedures through to new product research or major software development. But the key components that contribute to the success of a project are the same no matter how simple or complex the project is and whether it is being run in a small organisation without any formal project framework or in a large organisation as part of a well-established framework in an ongoing programme of projects and with the support of a project office.

The most important factors that will contribute to a project being completed successfully can be broadly broken down into the following 5 areas:

Strategic Planning

Understanding your marketplace, the wider industry and your competition is necessary so that the specific business objectives of the project can be well-defined and, more importantly, meet a genuine need, or anticipated need, within the market to which the end-product will be targeted. For simpler projects in small organisations the “marketplace” may, in fact, be a small internal team or department but the concept of understanding them and their objectives is still the same and still just as important.

Developing the Product

Any new product, process or service needs to be developed or established solely to meet the defined business goals, which need to be articulated and documented at the very beginning of the project. Where a project involves a new process, it is important to prevent it becoming an opportunity to add or change related processes where they do not add real business benefit and do not affect the final outcome or contribute to the overall business aims.


Focused marketing aimed at the right target audience is as vital for the simplest internal projects designed to change an existing operations process as it is to a new product with a global market. Of course, the realities of such marketing are quite different – internal projects are unlikely to have big-budget advertising campaigns for example – but it is still important to “sell” the product/process to those who will be buying or using it. In many internal projects involving major change to the status-quo the greatest challenge is to convince the end-users that they will be better off with the new process in the face of typical human reluctance to change.


For the wide variety of projects that take place in organisations year-round, the provision of a support mechanism both before and after implementation is another key component to the success of the project. Support might come in the form of IT support (providing the right hardware and software), Human Resources for recruiting and retaining the appropriate staff, facilities for providing the necessary offices or other building space and any number of other support services relevant to the project.


There are different categories of people involved in projects and they all have different and specific roles to play but they are all stakeholders with a vested interest in the project being a success:

  • Sponsor:- The sponsor(s) of a project is often a member of the senior management team of an organisation but can also be someone from outside the organisation if a strategic alliance has been set up. Their role is to define the business objectives that are the driving force behind the initiation of a project, to ensure that adequate resources are made available to complete the project and to influence the completion date of the project by defining priorities. They will tend to have a good overview of the project but not become involved in any of the detailed aspects.
  • Project Manager:- A professional project manager has the responsibility of creating a detailed project plan that meets the budget, schedule and scope determined by the sponsors. They advise, teach and motivate team members; resolve conflicts and issues with deliverables and deadlines and have a good understanding of all tasks required to complete the project. They also aim to manage and control risks and changes.
  • Team Member:– These can range from a subject-matter expert through to a recently hired novice but all team members will have a contribution to make towards the end-product. Each will be responsible for completing individual tasks to a deadline, including resolving issues that arise related to their tasks. More experienced members of the team should help the less-experienced members by answering questions and giving advice to maximise the ability of the whole team to deliver projects successfully.

So if you can get these 5 components right you will be able to do the following on your project:

  1. Clearly define the aims of the project
  2. Stay focussed only on those aims
  3. Successfully “sell” the project to the end-users
  4. Provide support for the whole project team as required
  5. Select a committed team that will work co-operatively

This will go a long way to ensuring that the final outcome of a project is a successful one. Of course, underlying all of these components and driving the project to success will be professionals who have gained on-the-job experience as well as completing project management training in a recognised methodology such as PMP or APMP.


What are the key factors in evaluating the success of a project?

Friday, January 20th, 2012

In the June 2011 edition of Project Manager Today magazine, I published an article called: “Complex, but not Complicated”, where I discussed how there are a number of generic parts/critical success factors whose influence on project success must be fully appreciated in order to achieve success.

So, what are the key success factors when evaluating the success of a project?  Or looking at it in a slightly different way, let’s think of this question as: “if we were to state that a project was as a success, what factors would we have looked at to come to this conclusion”?

Clearly, it depends on your definition or expectation of what success means. Remember that it is not within the scope of a project to realise the benefits resulting from the use of the produced outputs (some benefits maybe realised during the project, but most likely not all of them) – as a project can deliver its outputs on time, to cost, to quality but this is no guarantee that the benefits will manifest. I will add, however, that benefits realisation planning is one of the critical success factors of a project as if there is no view of how or whether the benefits can be realised, should the project start/continue? What I am saying is that the ‘physical act’ of realising the (majority of) benefits is not undertaken in the project.

Based on this, the correct project outputs need to be created – clearly – but is this all? Would you judge a project a success solely based on if it produced the required outputs? Think of it now in the situation where the project produced the desired outputs but the project plan was, how shall I put it, less than optimal. Success was achieved more from individual commitment than good project management.

Consider the following list. Would you consider these factors influence the success of a project?

  1. The organisational maturity in project management
  2. The robustness of the project governance structure
  3. An organisation’s consistent use of a project management method
  4. An organisation’s project management capability and capacity
  5. The organisational context in which the project operates
  6. An organisation’s culture
  7. The number of stakeholders impacted
  8. The number of stakeholders involved
  9. The degree of stakeholder commitment
  10. The value of the desired (potential) benefits (financial or otherwise)
  11. Whether an organisation has a ‘track record’ in this type of project
  12. The risk appetite of the organisation

I certainly do!

Success on a project is dependent on more than just producing the desired outputs. An organisation can deliver projects on time, to cost, to quality through individual commitment and, let’s be honest, luck. But luck runs out eventually.

For organisations to be consistently successful on projects a number of generic, non-technical factors need to be influenced also. In my experience, it is these success factors that are the critical ones.

Dr Ian Clarkson is Head of Project and Programme Management Product Development aQA -leading providers of Prince2 courses. His role provides business direction and ownership of QA’s portfolio, programme, project and risk management curriculum. Ian is an experienced lecturer, author, speaker and consultant, having delivered programmes and projects in all industry sectors.