Estimated reading time: 1 mins
In a recent post on her blog, Elizabeth Harrin shares with us some research from Forrester which (in her words) reminds us that projects are about people, not technology.
Elizabeth Harrin is a blogger (a girl’s guide to project management) who won the ComputerWeekly 2008 IT Blog Awards in the Project Management category. Her post summarizes the research which talks about the selection of good people on your project, and that good people come with good recruitment practices. I recently wrote about Ten Real Reasons Why IT Projects Fail and at number 9 was ‘The Wrong People’. The reasons weren’t in ranked order, but if they were then this would be at the top.
I was reminded again last week when I heard from an old friend based in Idaho telling me he had recruited onto a multi-million dollar project a technical expert in SOA who had passed his interview with flying colors because he was a guru in the subject. What the recruitment process didn’t find though that he had some interesting personality traits, like shouting at people, ignoring women on grounds of their gender, and a total disregard for business ownership. It is a nightmare in which my friend is struggling to recover from. His personal reputation hangs in the balance.
Check out these similar posts:
- Sh.. IT Happens #5
- Why Projects Fail
- Project Management For Dummies (and Non-Dummies)
- Ten Web-Based Project Management Tools
- What’s Holding You Back?
5 thoughts on “Projects Are About People, Not Technology (According To Elizabeth Harrin)”
Thanks for mentioning this – glad you thought my summary of the research was useful!
I could not agree with you more. Project management is much more about people management then the technicals.
If the project reaches deployment, then increasing user adoption of the newly deployed technologies is more a soft sell skill (again people), then a technical rational.
@Michael – you’re bang on I think. I don’t know about you but I’ve seen so many projects fail to deliver the *real* business benefits (i.e. people use the final product) because they’ve been ignored through the project. It’s like projects are ‘done to’ people rather than ‘done for’ people.
I’ve written two posts that illustrate this – one is a personal goof of mine:
A Painful Reminder About Change Management
15 Blunders to Avoid when Implementing BPM
@Michael : I have been involvd in project where the users were heavily involved right the way through and they drove the activitys a lot of the time so I suppose their ownership was very clear which meant they adopted the software afterwards very well! I have seen other project where they were very distant and then didn’t really know what to expect when the s/ware was given to them at the end! Ended up that lots of money was wasted
I just lost my 20 min comment!!Simon you have a dodgy website mate :)!! lol
Loving your feeds Simon!
I totally agree. It’s all about the right type of People (personalities) not just Technology…
Working in a programming environment you simply can’t have a joker join the team. It will cause constant mental breaks & annoy team members.
On the other hand you might employ a person who has a solid technical background but takes 4 hours to get to a simple 20 minute solution. It doesn’t help having a person join a ‘fast pace/thinking on your toes’ type of IT crowd as it will weigh the rest of the team down.
Touching on Project teams. If a Project Manager works in isolation to key resources simply because they don’t get along it becomes detrimental to the delivery. It will cause confrontations & affect deadlines.
Team building is vital to gain buy-in, build relationships & commitment to the goal. Having a good working relationship promotes a happy atmosphere & strong sense of achievement.