March 5, 2012
Posted by on
Project management principles are the same world over. However, the application of those principles vary widely depending on the type of organisation you are in and the type of external pressures you face. Here I use the word external to mean influences outside the project, rather than the organisation. PMBOK and PRINCE2 contend that the Project Manager runs the project on behalf of the governance team or the project board, so the decision on project selection and business case rests with them. Most organisations will use the experience of a Project Manager to determine the business case.
I work for a niche technology company that predominantly provides professional services and software development. Recently we have moved into the product sale market. One constant pressure we face is to limit costs of professional services in order to land a product sale. This is not unique to our company. There is always a judgement call between the appetite for cost the customer has in determining the final price. Regardless of the pressure, the effort required to deliver the outcome the customer is after does not change.
When there is internal pressure to reduce estimates, the Project Manager can negotiate with the sales staff to reduce scope as a trade off. That does not always work, as professional services companies are rarely in the position of setting the agenda. More often than not, they are responding to a demand based on gaps in the customers core staff. Usually everything is a must have. The question at this point becomes not a project management one, but a strategic one for the company. The project may be desirable despite possible overruns in the current project. There may be future projects, or may provide foot in the door to a particular segment of the market or may be a key reference customer. It is the Project Manager’s responsibility to quantify the cost appropriately, so the management can make an informed choice about how much risk they wish to carry. Simply adhering to the wishes of the sales staff is a dangerous game to play.
A second external pressure that constantly challenges project estimates is the pricing of competitors. This is a more difficult proposition to deal with, as the parties are outside the organisation and you will never have the full facts to compare your estimates. The opposition may be desperate and willing to undercut any estimate you provide. Equally, they could be significantly underestimating the risks and deliverables. The key here is to not look at your competitors on a project basis. Look at the pattern over a period of time and see if they are making a success of those projects where you are being undercut. If they are, then challenge your teams to sharpen their estimates. Be mindful though, there will always be cowboys in the market and clients willing to make to do on shoe strings. If that is the case, move on. Choosing to compete at that end of the market will be at the cost of reputation and professional satisfaction.
A third challenge a project manager faces is trying to recommend when a project should be terminated. Usually business cases are made to start a project. It is less common to continually validate the benefits sought in the business case as the project is in flight. Things can get complicated if it is a pet project of someone higher up in the organisation. It is imperative that a Project Manager is aware of what benefits are expected out of the project. That will allow for quantifying accurately if the benefits sought can be achieved based on realities of the project. Nothing is black and white in projects. That is why they are temporary and higher risk than Business As Usual activities. In some cases the organisation may decide risk to reputation is worse than loss in a project.
Projects are inherently risky and pressures are a fact of life. How we deal with the risk and how we quantify it to management is where a good Project Manager stands out. It is the organisation that makes the decision, but it is the Project Manager that provides the analysis to facilitate that decision.
September 29, 2011
Posted by on
I was talking to a fellow project manager today discussing how our projects are run. During the discussion it was apparent that I was speaking to someone that had very clear views on how projects should be run. So much so, that all things needed to run in a very prescribed manner.
I was intrigued at such a dogmatic nature of his management style. So I probed more about some of his reasons behind his approach. To start with, my intention was to understand if I was missing something by not following a methodology in such a strict manner. Suddenly the shutters went up and I was told in no uncertain terms that I was a discredit to my profession for having the temerity to ask questions of such nature.
The project manager I was following PRINCE2, something very close to my heart. I pointed out that one of the principles of the methodology is to tailor it to the project. That was indeed the last straw and the end of the discussion. This whole episode reminded me of people that preach religion. If you ask any questions, they look at you as if it is so obvious and you should be so grateful to receive the message. If you ask a legitimate question, they start getting defensive. If their particular argument has merit, they should be able to articulate that.
All the major religions in the world teach the same things – love for others, consideration for all, humanity, rights of people, taking care of the ill, poor and the less fortunate etc. Each have their own way of getting there. Similarly, project management practice has many methodologies. Mostly they provide similar guidance. Treat project management zealots in the same way you would treat the religious zealots. PRINCE2, PMI, agile … these are equally appropriate methodologies to meet your objectives.
Tailor the methodology to suit the project, don’t shoehorn the project to fit the methodology. That will be utter madness!
September 26, 2011
Posted by on
Yesterday, I was looking at the PRINCE2 manual for a highlight report content for a project. As I was doing my reading, I found myself going through some other topics before I got to the specific topic I was looking for. Suddenly, occurred to me that I could just use a Google search to quicken the process. That got me thinking … how does technology and modern communication methods impact project management practices?
I am one that prefers reading books as a way of learning. A good thing about books is that you don’t necessarily find what you are looking for at the first glance. In search of highlight report content, I ended up reading some other materials within the manual. This is knowledge I gained or refreshed, which I did not set out to. Using a search engine like Google would have meant I would never had the reason to learn what I did. Downside is that it took me longer to get to my objective. Depending on your point of view, this could be a good thing or bad.
The odds are if you have found this blog post, you have come through a search engine. What that opens up is access to a range of opinion that was previously only accessible through your professional networking. In the case of new project managers it was a significant barrier to professional development. While you now have a significant resource pool, it is difficult to verify the track records of the bloggers. The key here is to use your own judgement. Do not take any particular opinion as gospel.
New media has also changed the mindset of consumers. People no longer expect to be fed information. Projects are much more collaborative and agile than ever before. People need to feel they are engaged, rather than being dictated to. This enables opportunities for a lot of delegation of responsibilities to ensure appropriate handling of project execution. This however has introduced additional challenges in monitoring and control. At the same time, it makes it much more practical to manage the projects through real time logging and tracking of issues and risks.
Like all other aspects of life, new communication media is changing the way we manage projects. People do things differently now than they used to previously. The pace of change is quicker now than ever before. As project managers, we manage projects and by extension people within them, to get a successful outcome. We need to be adaptable to ensure we run with the times.
It is neither better nor worse … it is just different.
July 31, 2011
Posted by on
I recently did my MSP certification, to gain better understanding of programme environments, compared to projects. One thing that came as a slight surprise to me was the difference in focus between projects and programmes. Projects are focused about providing fit for purpose products within a certain tolerances – time, cost, scope, quality, risk and benefits. Programmes are instead focused an realisation of benefits.
PRINCE2 does have a focus on benefits. However, it also acknowledges that in all likelihood the benefits from the project outputs are likely to be realised some time after the project is delivered and closed. In that scenario, how do you make sure that those benefits are indeed realised? This is where the programme comes into its elements. OGC explains programme as designed to bring in a transformational change in an organisation and providing a framework for achieving that. When you think about that, it does make sense. An organisation doesn’t go into a project becase it wants to do a project. The reason they do it is to achieve a change that meets their strategic objectives.
The journey from inception of an idea to the actual realisation of benefits arising from that may not be a simple one. Ideas are inherently a vision from someone within the organisation that visualizes a future state of the organisation that is desirable. Ideas have to be tested for their merit, analysed against costs, implementation options considered. The end state can be a journey through fuzziness. This however, is not always the case. Sometimes the changes wanted are through known specifications, well understood and repeatable methods. In those circumstances, it is probably not worth running programmes. Projects are probably sufficient. However, fuzzier the journey is from vision to the future state, programmes are the way to go.
I thoroughly recommend the MSP approach to programme management.
July 17, 2011
Posted by on
I was talking to a friend who mentioned he was unhappy with the project he was involved in. His complaint was with his project manager, who he felt did not understand his field of work and set unrealistic expectations. At the time I did my friendly duties and sympathised with him. It got me thinking … do project managers need technical background?
I come for a software development background and am currently managing projects for a software and services company. I recall my early days as a developer when I had a project manager from an electronics manufacturing background. She could never understand the fact that developers can never give an exact estimate of a task. Another thing she never quite got to grips with is the difference of ability between the top developers and someone just starting out. This caused no end of frustration on both sides.
I have also worked under a project manager who was himself a developer in a previous life. While he understood how developers and development teams worked, he was very lax with his planning and issue management. We always felt we were fighting fires than working in a planned and organised fashion. That led to stress levels off the scale and we lost some good developers who could not be bothered working in such an environment.
Equally, I have worked under project managers of both ilk who have been more than useful. Now that I am managing projects, I am trying to judge if it is an advantage for me to manage development projects and teams. I definitely find my background useful. I know to understand tendency of various developers, understand when developers say 3 days – it is only for coding it, not to deliver it! If I had come from a different background, I would need to learn these nuances to be as effective. I find developers also find it easier to relate to me because of my background. What I try to guard against is the urge to have a look at code. I tell the developers …
The nature of the company I work for means I also have a team of non developers working on the same projects. These are geospatial analysts. While I did not start out in this field, I have picked up more than enough over the years to understand and influence how work is done. I now consider both geospatial and development as my technical background. This tells me you can learn new skills in a different field. PRINCE2 also contends that a project manager is managing projects to given parameters and should not require specialist skills. That is the domain of the team leaders.
My verdict … you do not need a technical background to be a successful project manager, but it definitely helps.