PM in Practice

I am a professional services practice manager with current accreditations in project, programme, and portfolio management. I have experience of delivering software and consulting services to international ports, climate change sector, transportation, and the public sector in New Zealand and the United States. Several of those deliveries have won international accolades. I have a Bachelors degree in computing and am currently pursuing an Executive MBA, am a member of the Project Management Institute, and a committee member of the Prince2 User Group. I share my professional views with my peers through my blog Project Management in Practice, and twitter.

About this Blog


Recent Posts

Agile or not?

Are the days of MS Project numbered?

Opposite of job dissatisfaction is not job satisfaction … what do you mean?

What can accounting and finance teach project and program management?

Do managers need technical background

Agile or not?

Categories: Agile, Estimation

Project delivery in the IT space is a fun job. You get to do interesting things, usually no two things are exactly the same and in the process get to play with technology. Life couldn’t be better. That is until you run into some oddities. Agile methods have not been everyone’s cup of tea. Ambiguity is the enemy of most bureaucratic environments. Before committing to any spends, they want assurances in triplicate exactly what they would get for the project, when, and in what manner. By definition killing any agility.

Republished from my blog Project Management in Practice.

What is interesting is that some of these organisations appear to be embracing Agile, but not because they want continuous improvement, or are looking to deal with ambiguity differently. They have found the dreaded requirements analysis phase of a waterfall project does not necessarily capture the requirements correctly, and consequently deliveries do not meet the outcome they set out to. Pushing that detail to be worked through in an Agile development method makes perfect sense.

Pushing the resolution of ambiguity later in the development phase means at the project initiation that ambiguity still remains. So any contracting for those services can only give you an estimate to a particular level of detail. What I find in many cases is there is little room for ambiguity when contracting for those services. The bean counters still want to know exactly what you will deliver, when, and how – so when the auditors turn up, they can show a clean bill of health.

As IT practitioners we have done a good job of convincing organisations of the benefits of Agile deliveries. However, we are yet to convince procurement that effort estimation is relative to the ambiguity that has been clarified. Wherever bureaucracy is involved, there appears to be a mismatch of expectations. It is not helped by IT companies willing to do business sometimes ignore their practitioners to take such projects and perpetuate this expectation.

What are you finding out there? Is this the norm or the anomaly?

Image credit:

Related articles
Posted on: July 16, 2015 09:58 PM | Permalink | Comments (0)

Are the days of MS Project numbered?

Categories: MS Project, Tools

Using MS Project is a bit of a right of passage for most people that have done project management in an enterprise scale. While many have grizzled and grumbled about the application, for a long time it was really the only one that would allow you to do what you needed to get done. What made it worse was between 1998 and 2010, there had been little new in terms of functionality and user interface that made life easy. With 2010 (and 2013) with the development of Project Server, Microsoft has added a few useful functionality.

Reposted from my blog Project Management in Practice.

A lot of web development folk had already deserted MS Project (or never used to begin with). The likes of Basecamp and Jira had been very popular. But there remains a good proportion of traditional PMOs that will require you to provide information and updates in MS Project format. So we could never really get rid of it.


Also gone are the days when everyone in the enterprise uses a bog standard OS and store things in a common location on the network. People are more mobile. BYOD is pervasive in most organisations. Many use Mac laptops, iOS or Android devices while on the move. If you subscribe to Office 365 on a Mac, you cannnot event get MS Project. While Microsoft addressed some issues with Project Server, many of its Project Web Access functionality didn’t work properly outside IE.

I recently came across Gantter from I am pretty impressed by what I see. The main Gantt view pretty much looks like MS Project. Rather than taking a lot of MS project functionality, they look to have taken the most used ones – tasks, resources, calendars, and baselines. It has even added one thing that plagues most Project Managers (and ends up getting managed in spreadsheets) – Risks!

Gantter can be integrated with Google Drive or Apps and allows you to have real time editing and chat with other Google users. It also allows you to save your projects into your OneDrive or DropBox storage. It can load projects from MS Project and also export to that format. There are plenty of default templates to get you going, or you can create your own. The best part is … it’s free. No longer do you have to pay exorbitant fees for MS Project.

I’ve only just started using Gantter. So final judgement is still pending. However, based on what I can see to date, MS Project’s days may finally be numbered. Even if you’re forced to report in that format by your customers.

Posted on: February 09, 2015 06:02 PM | Permalink | Comments (4)

Opposite of job dissatisfaction is not job satisfaction … what do you mean?

Categories: Behavior, People

Reading endless research papers for my MBA may finally be paying off. I’m finding one or two gems. This one from Frederick Herzberg is one such article. He contends that dissatisfaction and satisfaction actually contends with two different human needs. First, being the nature to avoid pain from the environment, second being our drive and ability to achieve. Therefore they are in fact not opposites of each other. Does this tally up?

Re-posted from my blog Management in Practice.

Opposite of job dissatisfaction is not job satisfaction ... what do you mean

In most staff surveys the number one complaints I can remember are to do with company policies and administration. Timesheet system is crap, too many meetings, things too slow to move, my manager is a !@$!@% are some of the most common ones. Closely followed are to do with working conditions – stress, balance of personal life, relationship with peers, pay etc. Herzberg calls these the hygiene factor of jobs.

I work in the field of IT. In most cases, people are reasonably well compensated. I hardly see anyone leave jobs for these reasons. I see far more people leave jobs because they cannot advance themselves (lack of training), the work itself doesn’t challenge them, they don’t feel recognised for their work or don’t find a sense of personal achievement in their jobs. Herzberg calls these the motivating factors of jobs.

The situation may be different in other blue collar jobs. While it is tempting to lump all my colleagues past and present into a single bucket, I’ll avoid that. Instead, if I think of my career to date, I tend to find it quite plausible. Hygiene factors have to tip the balance so much more than the motivating factors to influence me to stay of move on. So Herzberg has my affirmative vote on this one.

Why does this matter for management? One typical weakness in management is our focus on things that make the loudest noise. It is easy to identify the hygiene factors and express how dissatisfied you are. As managers we spend lots of time trying to make those go away. That actually doesn’t motivate us as much. All it does is takes an irritation away. Our productivity and ultimately job satisfaction rests on the motivating factors … why we work.

I’m keen to hear your views. Does this thought hold true elsewhere?

In case the link expires, the full APA reference is Herzberg, F. (1987). One more time: How do you motivate your employees? Harvard Business Review(September-October), 5-16.

Image credit:

Posted on: October 23, 2014 01:19 AM | Permalink | Comments (1)

What can accounting and finance teach project and program management? two decades ago I took one accounting paper and did just enough studying to pass it. I was studying for an IT degree at the time and only did the paper as it was a compulsory one. Wheels have now turned enough for me to come back to doing an MBA and by coincidence, starting back with accounting as my first paper. Today though my attitude is different. I can see use of quite a few accounting principles in managing projects, programs and portfolios – be it the IT domain or any other.

Reposted from my blog Project, Program and Portfolio Management in Practice.

What is a project?

Neither of the two main project management bodies have very similar definitions of project.

… a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case – PRINCE2

… temporary in that it has defined beginning and end in time, defined scope and resources … unique that it is not a routine operation – PMI

What is the shortcoming in both definitions? Both are approaching the project from the point of view of those that are charged to deliver the outputs. Project teams do not undertake projects because they think it is a good idea. Where is the customer in all of this? It can be argued that the mention of the business case in the PRINCE2 definition means it now represents what the customer gets out of it. None of these are as clear as the accounting definition of project

an investment that increases the wealth of the owners.

You can define the terms owner and wealth to what is appropriate in your context. But this definition is the most focused one that I have found anywhere. If anyone was unclear as to the outcome they should be delivering, this leaves no room for doubt.

Is this project/program worth investing in?

Business cases for projects contain all manner of justifications. Accounting and finance provide the mechanisms for relative comparison. Whether justification is based on additional cashflows, reduced expenditure, or increased efficiency accounting provides mechanisms to objectively compare them. Key strength of accounting is it takes into account the time value of money too. A dollar earned today is much more valuable than a dollar earned sometime in future. The concept of Net Present Value (NPV) provides a way to compare cashflows that are invaluable tools for such comparison. Accounting also has very clear formulas to calculate break even points given different amounts of fixed and variable costs. Many business cases fail to address these fundamentals. It should be mandatory for those involved in preparing and evaluating business cases to have understanding of these concepts.

How is it going?

Accounting is full of metrics. Whether you are measuring efficiency, turnover, income, cash conversion cycle (how long before you lay money out for raw materials to when you get paid for it), what a share or bond should be worth etc. The closest project management comes in a traditional sense is earned value management (EVM) and more recently the burn down charts in some of the agile practices. Some service management organizations are better at it. They do measure mean time to failure and restore among other operational metrics. Singular focus on analysis and improvement on these is something project management can learn from.

How do I report?

I have seen and prepared all manner of project reports. If I don’t see another Red Amber Green report, I don’t think my life will miss much. While these reports are useful in getting our eyes focus on likely areas of problems they are pretty useless in contextualizing what the problem is. This is where accounting leads just about any profession. Generally accepted accounting principles (GAAP) mandates interpretations of exactly how reporting is undertaken. I am somewhat generalizing to make a point about standardization of reporting.

Does that mean accounting and finance have it all over project management? Not quite. The two are totally different disciplines. You can equally play the accounting system as the likes of Enron, Fanny Mae and Freddy Mac would attest to. The key is to take the strengths of other professions and make ours even stronger. As I go through some other papers I feel there may be a few more posts coming titled what can ” ” teach …

What parallels with other professions can you see?

Image credit:

Posted on: May 30, 2014 12:43 AM | Permalink | Comments (0)

Do managers need technical background

Categories: Leadership, Stakeholder

Couple of years ago I wrote a post on whether managers needed technical background to be successful. That article had a specific focus on project management. I have recently been thinking about the same topic on a slightly different context.

Re-posted from my blog Project Management in Practice.

I recently embarked on an Executive MBA. The first paper I’m taking for the course is Accounting. The aim of the paper is not to turn managers into accountants, but to enable them to make sense of accounts, the information these give and what can be used to make management decisions. My study group contains an executive from local government, a consultant that works with ministers and mayors, a statistical analyst from a government department. I manage part of an IT professional services consultancy. We all seem to have forged successful careers which require interpretation and forecasting of financial information without being accountants. So I wondered important is domain knowledge really?

You can argue that we have taken up MBA precisely because we may have realised there is a gap in our expertise. There is an element of truth to that. Let’s explore this further. Most professional careers will require you to have some sort of qualification. Whoever is the team leader in that setting is one that is appointed on the basis of their experience and/or expertise in that area. It can be helpful in the next step up to managing business units as well. Once you get to group / divisional level usually domain knowledge is less helpful. You require expertise in other areas of business to be successful. Executives in your business may have little or no knowledge of the particular domain area, but they will usually bring significant strategy and business knowledge.

There are different skills required in different areas of management. Can you effectively devise strategy if you had no domain knowledge of the business. The answer is no. This is where senior managers use domain expertise to bounce ideas off, find what is feasible and risks and rewards of various approaches. Senior managers are judged by their ability to understand the totality of a business and impact of choices that get best outcome for the enterprise.

This need to get away from the details at certain levels is why many brilliant technical staff do not necessarily make great managers. Those that wish to move up the chain will at some point have to give up their control of specific areas they look after (be it engineering, software development, teaching) and trust others to provide the expertise and spend the time understanding the business as a whole. This is not an easy thing to let go of.

So my conclusion today is slightly modified from the one I had made a couple of years ago. Managers with domain knowledge is only useful up to a certain level in the organisation.


Photo image credit:

Posted on: March 15, 2014 01:09 AM | Permalink | Comments (0)

I've never heard of a relationship being affected by punctuation.

- Jerry Seinfeld