Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Project manager

When Project Managers can be dangerous


When project managers can be dangerousAs Project Managers we are in the business of control and order. We are placed in a position of trust to achieve the desired outcomes. Most actions we take usually reflect this. The other day I was nearly caught out by something and was rescued by my architect. The worst consequence would have been some lost time in discussion. That made me think, can project managers be dangerous on projects sometimes? I think yes. Here are my top 5.

1. Know too much

This was my problem. Having come from a technical background, I thought I knew something when I only knew part of it. I enjoy keeping in touch with technology and am usually good at knowing when to shut up and let the experts lead. Usually this technical knowledge gives me a good insight to ask questions on approach, probe for weakness. On this particular occasion I could have sent the discussion on a tangent. A position of authority usually brings with it a level of credibility. If you overreach your knowledge there is a risk that people will not challenge it. Project Managers must know their limits. It always pays to have in your team that are willing to ask questions and willing to correct you if you are in the wrong.

2. Know not enough

It may sound like I am trying to have my cake and eat it too. Just as overreaching your knowledge can be problematic, so can be being totally oblivious to problems. Project Management text books will have you believe you need no content knowledge when managing projects. While that can be true, it can only succeed when you have able technical expertise on tap. That is not always available unless the project is of a certain size. The best way to build credibility with your team is to demonstrate you know what success looks like. You can only do that with some content background or the help of a very able lieutenant.

3. Project going too well

Things going too well early in a project is sometimes is just about the worst thing that can happen. It may sound counter intuitive. I have too many occasions where Project Managers get lazy and forget to pay attention to the important things – recording decisions, deviations from scope, paying attention to risks etc. Projects are risky endeavours. Experience tells us that not everything will go to plan during the project. If you have grown lazy with a good start, you can be guaranteed difficulty ahead when the worm turns. When Fred Brooks Jr, the father of IBM 360 was asked how one of his projects got to be twelve months late he responded … one day at a time.

4. Becoming rigid

There is a tendency sometimes to manage by actions rather than outcomes. Our goal is not to deliver the actions in the plan, but the outcome in the business case. Project plans must be living plans. There will often be the need to adjust course to get the best outcome. Sticking to prearranged plans will give you a great Gantt chart with beautiful baselines. Sometimes you can deliver to exact plans and deliver no benefits to your customer. Your plan must have some slack, so as to not fall over at the first risk. Allow yourself the flexibility of not using 100% allocation. Expect some sickness, administrative times, training needs for project team members. Avoid having to hand a change notice every day. Project Managers must understand the difference between being in the right and getting the right outcome.

5. Spreading chaos

There will always be an element of pressure on the Project Manager. We get paid to navigate the team through uncertainties. Sometimes progress is not what we hope for. From time to time we face unrealistic expectations from our own management or customers. There are various ways to handle that pressure. The one thing you must avoid is spreading that feeling of pressure to the project team. Even in most difficult cases if shield your team from some of the external pressures you have a reasonable chance to salvage something out of the situation. If you let your pressures on to your team, chaos will ensue.

I’m sure there are many other ways we can compromise a project. I would be keen to hear your thoughts.

Image Credit: http://www.techweekeurope.co.uk

How much financial knowledge do Project Managers need?


I attended a training seminar the other day on finance and accounting for non financial managers. It was an interesting training course. If you consider the constraints within which project managers must work to, one is financial. The last time I studied anything remotely close was accounting 101 during the first year of my under graduate degree some 17 years ago.

How much financial knowledge to Project Managers need

The course was run by Victoria University Professional and Executive Development school. Not being a student of accounting and finance, the seminar title seemed like exactly something that I’d be able to use in my project management role. As the course outline was being set out, I realised this was probably the wrong form of accounting for me. The primary focus was on accounting concepts and how to understand company accounts and performance. It appears management accounting is what I should’ve been looking into for making decisions based on numbers.

While I didn’t totally achieve what I wanted to in terms of outcome, it wasn’t a total waste of time either. We focused on importance of cash and return on investment based on various capitalisation models. I had never thought to consider projects, or even business cases along those lines. It is a very useful knowledge to have when considering the straight ROI figures. I will be much wiser to attempts at manipulation along those lines.

This all made me think, how much financial knowledge o you really need to manage projects effectively? Projects are usually incurring expense until such time it is transitioned into the business. Usually project managers will not be responsible for the realisation of he benefits. That means unlike accounting, all the numbers are in one direction. That is why most project managers will be able to get away with limited or no accounting and finance knowledge, as long as te are reasonably good with numbers.

This all changes when the project manger becomes responsible for both generating income and controlling expenses, which is the case in supplier environments. I have a set number of resources that I can utilise for various projects. How I use these resources not only determines success, but also income for my team. In strict sense this is more akin to portfolio management, rather than project management. In this scenario, I found the focus on importance of cashflow and various funding models was very useful.

If you are running a programme that is designed to deliver a financial benefit, I can see a very practical application in terms of analysing if you’re meeting the desired profit targets. Similarly, if your benefits can be quantified in terms of monetary value, then understanding accounting and finance is very useful. However, in general I haven’t found the lack of understanding in this area hasn’t necessarily made life any more difficult, as I am comfortable with numbers in general.

My role involves more than simply managing projects. It also includes forecasting of revenues, participating in the sales process and contributing to strategy among others. I still think understanding management accounting may be very useful. I will probably look to get some more professional development in that area. Again, those in my view are more portfolio management in nature, rather than project management.

What has your experience been? Am I totally off track?

Image Credit: best-financemanager.com

How do I estimate based on risk?


Risk Management - Image from bigthink

Risk Management – Image from bigthink

I have previously contemplated the challenges of keeping to scope and budget and keeping customers happy. If a customer adds new requirements on to a project, it is an easy discussion to have around additional time and cost, or a reduction in scope elsewhere. Grey areas in scope aside, you can show a definite impact on the project because of an omission that needs to be rectified. Where I see challenges are in trying to prevent slow bleeds.

One approach is to state assumptions that all dependencies will be met and manage exceptions by change requests. From experience I find that is a hard way to manage. How long does it take to do a task? The answer is always depends. You may be doing a task very similar to that you have done elsewhere. However, you cannot assume it will take the same amount of effort or elapsed time. The environment where you are deploying, number of other suppliers involved and in-house expertise of your customer all play significant roles. Experience tells us that we must take into account these factors as risks when we estimate project cost and duration.

My area of expertise is in delivery of IT projects. However, I believe the principle is the same in all fields of work. In an IT context, even in simplest projects you will have a customer taking on the task of solving a business problem through a project. The supplier will be engaged to deliver the project to a scope. Usually interactions are required with subject matter experts in the business, the IT service provider for the customer (could be in-house or another supplier), possibly procurement … to note a few. There are risks that we must associate with each of the players and estimate the project accordingly. While it is difficult to create a good risk profile for a new customer, we should be able to build a reasonable picture for customers we deal with regularly.

Think of a scenario where one of the other suppliers delay delivering a component that is a pre-requisite for your delivery. It may only have been delivered a day or two late. However, you have created an optimum resourcing based on something being delivered on the agreed date. In reality, you cannot re-assign those resources unless you have significant notice of the delay. Even if you know well ahead of time, in many occasions it is impractical to re-allocate those resources to another project, due to the short available window. By the time they are up to speed with the other project, it will be time for them to start working on the original assignment. Effectively the supplier through no fault of their own ends up absorbing the cost.

Sometimes the lost time is less than days, maybe a few hours every week due to lax turnarounds to required information or pre-requisite delivery. However, at the end of a project it does end up being a significant impact. You cannot really go back with a change request every time something is delayed by an hour. This will give a new meaning to death by change request. And you can be guaranteed a breakdown in communication with your customer. How so do we then ensure projects do not suffer this fate?

PRINCE2 Risk Probability Impact Grid

PRINCE2 Risk Probability Impact Grid

The only way around this dilemma is to expect some level of these risks materialising. PRINCE2 suggests using a probability impact grid to evaluate risks. While PRINCE2 is predominantly useful for the end customer to run the project, there is no reason the suppliers cannot use similar techniques to analyse risk. It is worth analysing what your particular scale for impact or probability is to get a good feel for impact. When you are constructing your estimates and plans, have these built in.

The key message here is to initiate a change request only when the risk that you have tolerance for in your plan is exceeded. Many IT projects fail to take this into account and bleed. One can legitimately ask why doing a PERT estimate should not take these risks into account for the pessimistic scenario. The key to remember on that is when you get your technical staff to estimate the pessimistic scenario, they are taking into account pessimism from a technical point of view, whether that be an unknown pattern of software development, familiarising with new API etc. They are not taking into account human or communication risks.

In my observation, construction projects are better at taking risk budget into account than IT ones. This is possibly because a half finished construction project is an obvious reminder of a failed project. Failure of an IT project is usually a less visible eye sore. That has probably made those in IT projects lazier than we should be.

Project management lessons learned from a vacation


After nearly a two month hiatus in blog posts, it is time to jump back on the horse. In that time, I have spent five weeks on vacation and either side of it two and a bit weeks in doing handover and picking the work back again. I thought it would be useful to share lessons I learned from this exercise.

Project management lessons learned from a vacation

The Preparation

This is the most stressful part of going on a long vacation. I had worried about projects suffering in my absence due to lack of control or guidance. Clarity in decision making based on experience is a key skill of a Project Manager. As many Project Managers do, I still carry my cell phone during short holidays. There is always a fallback if the wheels start to wobble. On such a prolonged vacation overseas I was not about to entertain being on call. I therefore asked for a short term stand-in for my role. I involved in various projects during a two week period to ensure he had sufficient background in the processes we followed and status of the projects to carry them through for five weeks.

The Vacation

This was the first vacation of this length I had taken in nearly five years. Having done the legwork with my stand-in, I was surprisingly relaxed during the holiday. I cannot put my hand on heart and say I never worried. Anyone with a level of responsibility will from time to time worry about events beyond their control that they cannot steer their team through. Most of the incumbent project teams and support teams – sales and management – were still there. Needless to say I enjoyed my time off in the knowledge that with the handover I gave and the available support structure the risk of total cock-up was relatively low.

After the Vacation

On my return I was pleased to see three quarters of the activities were done as I had wanted. Some were left for my return that required a level of experience or authority to carry out. While there were some thing done slightly differently, I can accept that as best effort choices based on information at hand. One particular area was done better than I had expected – breaking development work packages into short sprints. The week following the vacation was spent trying to get back to the rhythm of work and getting a handover.

What the team learned

The team understood the consideration, communication and time it takes to make decisions on project related matters. Many a time some of these challenges are nto visible to the project team (or for management for that matter) and cannot be readily appreciated. The fact that quite a few decisions were deferred and a lot of the decisions required quite a bit of internal discussion gave them an appreciation of challenges I deal with on a daily manner.

What I learned

The biggest learning on my part is that I need to worry less about thing going wrong in my absence. My team is made up of some very capable people and are able to provide good guidance on how projects should be executed. I will probably look to see how I can take advantage of that to get some of them to provide more leadership. From a personal point of view, the vacation has enabled me to recharge my batteries and come back with renewed energy. I will also look to ensure my team gets the same opportunity.

It is good to be back. Keen to hear your learnings from similar experiences.

Image Credit: NewHotelsUs.Com

5 Questions every Project Manager must ask


5 Questions Project Manager must askProjects are inherently risky endeavours and require plenty of shepherding to ensure successful completion and the desired results. Key to successful project management is clarity of understanding on what you are trying to deliver. It is easier said than done. Different people can read the same requirements and have different impressions of deliverables. I’ve been thinking about some of the strategies I have used and seen successfully applied. Following is a set that I have found very useful. I find asking some, if not all of these questions consistently gives me best chance of success.

Q1: Can I focus on outcomes rather than outputs?

Most projects in my experience are too preoccupied with delivering the outputs. Predominant procurement methods are partly to blame for the culture of judging project success by its outputs. For example, an output may be a new software but the desired outcome is faster processing of orders. No one has monopoly on good ideas. In many instances requirements are gathered prior to projects starting, where assumptions fail on first inspection. Ask yourself if you have the ability to go back to the stakeholders if you were faced with such a scenario. If it is output that you must produce regardless of outcome, then your chances of success are low. On the other hand, if you know what the desired outcome is, you can articulate why a particular option may have more merit than another.

Q2: Do I have enough sponsor involvement?

I see plenty of projects languishing with project managers struggling to get buy in from various stakeholders. Any organisation is a political one by nature. There are stakeholders with various views. Some may have been keen to undertake the project; others may not have been so enthusiastic. Organisations have to prioritise their portfolio and you may require contribution from those that had their projects or ideas passed over. If you try to manage your way out of that, there is little hope of success. This is where involvement of your sponsor is key. They are usually in a position of authority to ensure cooperation, provide you with strategies to work within the organisation and remove obstacles before they become showstoppers.

Q3: Am I working to artificial deadlines?

I see many instances where projects are running to particular deadlines not because of level of effort required, but because someone in management has undertaken to have the outputs delivered at a certain date. Fred Brooks Jr, father of IBM/360 is one of my favourite authors. In his book “The Mythical Man Month” he gives a great example – It takes nine months childbirth. You can put nine women, you’ll get nine children, but it’ll take you nine months (paraphrasing). The effort is what it is. If artificial deadlines are to be met, it must come by trading off scope in the project. Simply throwing more staff at it does not solve the problem. In some cases you may be able to reduce elapsed time by throwing more resources. But beware, what takes one person 100 hours, will not be delivered by 100 people in one hour. There is a cost of communication and coordination.

Q4: How am I going to transition the outputs to the business?

So you have a set of outputs from the project … process, software, document, building … whatever these may be. Now what? The only way the customer can achieve any benefit out of these is once you have transitioned these into the business. I see many projects leaving transition planning to the end. That is always too late. The end of the project is usually a swarm of activity, many planned, many unplanned but necessary. You need to have planned your transition up front. Organisations have various levels of change appetite. You need to consider if you can take a big bang approach or need gradual transition into service.

Q5: What does my gut say?

If you are an experienced project manager, then trust your instincts. Our brains are programmed to catch patterns. You may get a feeling that something isn’t quite right. I have seen project managers ignore that if they have not been able to verify if there is indeed a need for concern. By the time they have realised what it is it is too late. If your gut tells you something is wrong, stay at it. Until you find out what it is. Have a method that you apply to it. Go through your risk register, deliverables, product descriptions, milestones. At first if you don’t see it, stay vigilant. Ignoring it is just about the worst thing you can do.

There are bound to be plenty of other questions that you should ask yourself. What is your list?

Image Credit: All-Free-Download.Com

%d bloggers like this: