What makes a good Project Manager?

When a project goes wrong the cause is often poor project management. 

So what makes a good Project Manager?  And are the best project managers those who have obtained a recognised qualification?

Without a doubt a qualification can provide a junior project manager with a set of tools that they can use to manage a project. But does that mean they are ready to successfully manage a project? 

What other skills should a project manager have?

Here are a few suggestions that as a Project Manager you need to consider: 

1. Are you comfortable with delivering bad news?
   This really is the kiss of death on a project if you aren’t.  Something will go wrong and the worst thing you can do is ignore it or even worse hide it. The sooner you make your senior stakeholders aware that there is a problem then the greater the chance of implementing measures to address the issue.
2. Saying ‘No’
   There are so many things you will need to be prepared to say ‘No’ to. It could be staff holidays, or working from home at a crucial time, or it might be negotiating with a stakeholder over changes that they believe are required.
3. Are you happy with telling people what needs to be done?
   Are you comfortable with giving instructions? Sometimes it is just not enough to ask. Sometimes you will need to tell a team member to do something. You need to be able to lead.
4. Team Building  
   It isn’t always the best team that wins the league or the worst team that gets relegated, sometimes it is the most motivated and the most committed and the one with the best team spirit which succeeds. It is the same with Project Teams. Your team might be made up of permanent staff, contractors and suppliers, all with different motivations.  You need to foster a culture so that when things go wrong, and they will, the whole team pulls together as one to deliver the project.
5. Are you flexible?
   Once the plan has been agreed do you doggedly stick to the plan?  The plan is only right at the point it has been agreed. Things will happen that will change the plan and you need to be flexible and adapt as changes happen. There is no disgrace in having to adapt as long as all involved understand.
6. Do you document?
   It is essential that all key decisions are documented. You never know when you will need to refer back to something. Particularly if the project starts to go wrong. Most people leave it too late or don’t do it at all.
7. Seeing the Big Picture
   It depends on the size of the project, and the devil is in the detail, but the project manager must see the bigger picture and when you micro manage you tend to lose that focus.
8. Relationships
   Probably one of the key skills that a Project Manager needs is the ability to build relationships. With their team, suppliers and also key stakeholders in the business. You need to know the people you are working with. Although everyone wants the project to succeed, they may all have different priorities and when those are conflicting you need to manage that and the best way is by having developed relationships.

Successfully Delivering a Software Project

You have decided to replace a key system, you have defined what you require and have selected the solution best able to meet those requirements so how do you deliver that project successfully to time and budget?

The trouble with technology, or process improvement, projects is that, even when buying packaged software, no two projects ever seem to be the same and there will be requirements that are unique to your organisation, particularly if there is some level of customisation   

However there are some sensible measures that can be taken to ensure project success: 

1. Have a plan. It sounds obvious but it is amazing how often projects don’t and if you don’t know where you are going you will end up somewhere else.  Your plan needs to be understandable and manageable so as with requirements gathering ‘big is not always beautiful’. The plan should be appropriate to the size of the project but make sure you have a plan and that it is understood. A 1000 task project plan is not something to be overly proud of as most people will not understand it and so something will go wrong.
2. Manage the Plan. The plan is not just a deliverable to be filed. It has to be managed as it will not look after itself.  Things will happen that may cause you to review the plan and possibly to adjust it. This doesn’t mean micro-management but it does mean regular project meetings both for the project team and the senior stakeholders and there needs to be a log of real risks and issues, i.e. ones that really will impact the project not hypothetical ones that fill up the log.
3. Manage Change: The plan and the project are not set in concrete. It is a fact of project life that requirements change. This can be for a whole bunch of reasons, the original requirement was misunderstood or a new requirement as a result of a strategic change in the organisation.Whatever the reason you need a process to manage change, so that those involved in the project understand how much it will cost, why it is necessary and the impact on the overall project. Then the decision can be made as to whether the change should be approved and when it should be implemented.
4. Be realistic with the Go live date. One of the reasons why software projects fail is because of unrealistic timescales. There are a number of reasons for this. Firstly there is the perception of it being packaged software, but with all packaged solutions there will still be configuration and testing as well as some elements such as interfaces and data migration that will be unique to that project. If there is an operational or legislative reason why the solution needs to be implemented by a certain date then that needs to have been incorporated from the beginning of the project. There is the tendency to be too optimistic but issuing deadline after deadline will only lead to distrust and aggravation on the part of the client and it takes a strong project manager to propose a realistic plan.
5. Manage expectations. Know who your stakeholders are and ensure that they are involved and informed. They all want the project to be a success but they want to know what is happening, when and how it will impact them. In particular nobody likes surprises. Ensure that there is regular communication appropriate to the stakeholder and their level of involvement.

Selecting Packaged Software

Selecting business software can be difficult. You know you need a new system, but how do you go about finding the correct solution for your needs? 

Finding the right software can be a challenge but the correct approach to selection will hopefully enable you to avoid the pitfalls, and having the right supplier to implement the chosen solution is just as important. 

Hopefully the following will help you to avoid some of the common pitfalls that companies make:

1. Selecting software is a project in its own right. It needs a plan and it needs a Project Manager. Most organisations have specific target dates for implementing new software, whether it be a strategic initiative or a legislative requirement. But without a plan, as in all things, you probably will not achieve it. 
2. Involve all stakeholders. Whether the original impetus for changing the solution was business led or technology led you need the input and buy-in from all the constituent parts that make up your organization. Ensure you understand the procurement process and that all the correct people are engaged from the beginning
3. Why are you buying a new system? Too many businesses purchase software thinking it will solve their problems when, in fact, the problems are actually due to business processes. Software is only a tool, although it may help you to focus attention on the bad processes and other internal problems that need to be addressed.
4. Do you know what you want? Do you know your requirements for the new system? If not stop and go no further until this has been done. It doesn’t have to be laborious but you should at the initial stage be able to document your key requirements, those criteria which differentiate your business, onto just a few pages. As a minimum you should know your key processes, end-to-end, and that includes their impact on other systems or organisations and hopefully the key areas that you are looking to improve. Knowing your requirements also includes knowing your budget. There is little point in looking at a Ferrari if you can only afford a Fiat, even if the Ferrari meets all your other requirements.
5. Assessing the software through a scripted software demonstrations. Initial software demos may be guided by the supplier but when you get to the shortlist you need to assess the solution based on your requirements. So at that point it should be a scripted demo. If the supplier can’t or won’t do what has been requested you should be asking why.
6. Assess the solution implementer. Some software packages will be implemented by a third party. so not only are you assessing the solution but you also need to assess the company that will implement.No matter how good the software, the set-up and configuration will only be as good as the company implementing it. So when you get to site reference visits you need to be referencing not only the system but also the implementer.

Getting Your Software Requirements Right

When selecting software, getting the requirements right is absolutely key to the success of the project. They are effectively the foundations for all that you to want to achieve.

If you get them wrong you will either end up with something that doesn’t meet the requirements and you have to start again, or it will add significant delay and cost to the project. 

So here are some principles for getting the requirements right:

1. If it is not written down it has never been said. It doesn’t matter if you talked about what your wanted at length, what matters is what was written down. And it is all that matters if when  the solution is delivered you discover that a key piece of functionality is missing
2. You don’t know what you don’t know. Get the prospective supplier to demo what is available in their system 
3. Do not design your system around exceptions, particularly if doing so requires customisation. Consider how the process might be catered for outside the system. Do you really need to allow for snow in summer?
4. Do not determine your requirements in silos. Consider the end to end process and make sure that you involve everyone that needs to be involved.
5. Customisation should be a last resort when buying an ‘off the shelf’ system. Question why your organisation is so different to anyone else.
6. Do not create a replica of your existing system, remember that there is a reason why you wanted to replace it. 
7. Big is not beautiful, when documenting your requirements. A 700 page requirements specification is not something to be proud of. Break it down into bite sized chunks so that it can be understood and signed off.
8. Take into account corporate strategy. Don’t just design a system for you immediate needs. Does your company plan to expand into other countries? What other systems are being replaced? What will happen if another company is acquired?
9. Something will get overlooked, hopefully it will be minor but you need a process to manage change so that you can make an informed decision in terms of impact to the business, as well as impact to the project including the budget.