Project Management in Practice

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

Agile is bad!


Not always. We have a tendency to solve problems we face with a single silver bullet. In the recent past, I observed an organisation trumpet it’s move to agile in multiple communications. This organisation had undoubted issues with delivering to commitments it had signed up for, and agile was seen as the way to fix all its ills. Yet, when I talk to those working in the organisation, they see little change. And surprisingly, the outcomes are no different now than before.

Agile-Or-Not

So is agile to blame for this? Or was waterfall methods (if indeed it was what they used) really to blame for their past failures. The reality is agile is not something that simply works. A cultural shift is required within the organisation to derive benefits from using any agile methodology. Without that, (so called) agile is just as bad as any other way of running projects. So what are the things that defeat agile in organisations?

Multi-disciplinary teams: Agile project teams must include subject matter experts from areas that they are delivering too. If a software is being written for automating taxes for accountants, then you must have accountants and tax specialists in your project team, along with your developers, testers etc. Technical staff cannot be experts, and this is why you will need subject matter experts. If experts get tasked with duties on top of their day job rather than dedicated time on the project, agile is bad for this organisation.

Decision autonomy: You get over the first hurdle and have the skills in the team that you need. Time comes to make the first choice between implementation options and your subject matter expert needs to get it approved by their manager, who is not available for rest of the week. If your subject matter expert cannot make decisions on the project with authority, agile is bad for for this organisation.

Urgency: A key tenet of agile is the delivery of working product at the end of each iteration. Iterations are intentionally kept short so prioritisation always focuses on highest value items, builds value incrementally, and avoids the bells and whistle distractions. If the organisation cannot get you decisions in a timely fashion, then you can be guaranteed to either twiddle your thumbs for parts of iterations, or pull too many moving parts into it. Either way, agile is bad for this organisation.

Change control: It is all well and good for the project team to work in an agile environment. What happens to the working product delivered by the team? Is the organisation geered towards receiving these products at such intervals? Can they cope technically? Is there enough staff to make it happen? Can the required training be produced in time? If the answer to these questions is no, then agile is bad for this organisation.

Procurement and audit: Agile planning is done in stages. Closer you are to working on an item, more detailed planning you undertake. In the course of the project, it may become clearer that delivering more in one area is of higher value than delivering on another that had initially been identified as a requirement. If the subject matter experts make this call and the organisation’s procurement or audit team later lambasts them for non compliance, agile is bad for this organisation.

The intent here is not to highlight deficiencies of agile methods. In fact to the contrary. Agile done well can be immensely valuable for organisations and an innovative and satisfying environment to work in. The key is to recognise agile requires a cultural shift in the way an organisation operates to make it truly worthwhile. You do not make agile project teams, you make agile organisations.

What motivates the New Zealand IT Professional?


I have just recently completed my Executive MBA. The final piece of the puzzle was a research project of my choice. I had always been interested in what motivates those in my industry. A great many also helped me by responding to the study, and therefore this is my attempt to thank them by sharing my findings.

Get the PDF summary here.

A massive ocean of literature exists on the topic of motivation. It can sometimes be a hindrance rather than assistance for IT management professionals. Some studies claim IT professionals are unique in their attitude to motivation and job satisfaction. With move towards a knowledge economy, understanding of these factors will play crucial role in future success of organizations. In addition, a shortage of skilled professionals may contribute to unique motivators in New Zealand. This research therefore aims to answer what motivates the New Zealand IT professional.

Herzberg’s Motivation Hygiene Theory
Contrary to previous assumption, Herzberg contends job satisfaction (motivation) and dissatisfaction (hygiene) were distinct in their contributors rather than two ends of the same scale. Resolving something that makes one dissatisfied does not provide job satisfaction. It merely reduces dissatisfaction. This is the theoretical basis of the study.

Method
A modified model of Herzberg’s Motivation Hygiene theory by Smerek and Peterson was used for this study. A self completion questionnaire was distributed online through SurveyMonkey to a population of IT professionals accessed via a LinkedIn group. Partial least squared, a structural equation modelling based technique was used as the primary method to understand relationship between the various dimensions of job satisfaction, impact of personal and job characteristics, and turnover intent. Follow up interviews were conducted for validation of analysis results and to understand weaknesses of the study.

Participants

Screen Shot 2016-02-19 at 1.05.27 PMScreen Shot 2016-02-19 at 1.03.38 PM

Finding

Screen Shot 2016-03-18 at 12.12.36 AM

Relative Effect

Screen Shot 2016-04-11 at 10.48.30 PM.png

Recommendations

  1. Focus on a motivated workforce to ensure top talent is retained. Lack of job satisfaction is primarily why they consider leaving.
  2. Focus on the nature of the job. What they do and how much responsibility is afforded to them are the key predictors of job satisfaction.
  3. Train supervisors to provide an empowering environment. Perception of how enabling supervisors are, contributes significantly to job satisfaction.
  4. Offer competitive salary to retain top talent. While salary is not as strong a predictor of job satisfaction as the nature of the job, responsibility, and satisfaction with supervisor, it still shows positive association.
  5. Do not hesitate to employ IT professionals born outside New Zealand. There are no significant differences between New Zealand born IT professionals and those born overseas.

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: smokejumperstrategy.com

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.

Gantter

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 smartapps.com. 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.

Follow

Get every new post delivered to your Inbox.

Join 924 other followers

%d bloggers like this: