Project Management in Practice

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

Research invitation: Motivation among IT professionals in New Zealand

Motivation among IT Professionals in New ZealandI am currently undertaking research on motivation among IT professionals in New Zealand as part of my MBA. I would welcome your input. Complete the survey and be it to win two $50 vouchers. More than happy to share my findings with anyone that participates. Feel free to pass on the survey to anyone else you think may be interested too.

SurveyMonkey Link: Motivation among IT Professionals in New Zealand.

Agile or not?

Agile-Or-NotProject 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.

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:

Are the days of MS Project numbered?

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.

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.

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

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?

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:

What can accounting and finance teach project and program management?

what-can-accounting-and-finance-teach-us-about-project-program-managementNearly 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.

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:

Enhanced by Zemanta

Get every new post delivered to your Inbox.

Join 845 other followers

%d bloggers like this: