IT Project Management - life on the front line

I was sent these videos earlier on the way Spotify operates. It looks a lot closer to Agile utopia than many companies. Well worth a watch: Part 1 Part 2 If this doesn't make you want to be more Agile at work then I despair! Maybe we'll never get to this level but we can keep trying. The bad news?  Most workplaces I've experienced have been a huge distance from this experience. The good news? I wasn't sent these video links by one of my cutting edge start-up contacts, but by a Head-of Delivery in a major European Insurance company.  The desire is there and it's moving up through the hierarchy. The slow realisation that the way in which they create, buy and deploy tech is paramount is dawning. Let's focus on doing it the right way and learn from the hard lessons of other industries. Mining and textiles were thrown away in the UK in the pursuit of being cheap (at the cost of quality - and jobs). The British Automotive Industry fell apart i...

If I asked what qualifies someone to lead an IT Project you might immediately think of literal qualifications; a degree, a PRINCE2 practitioner certificate, DSDM certification. You might think of the practical skills needed to achieve Project Management tasks; the ability to plan, management of RAID/CARDI items, stakeholder communication. All of these things are vital to managing a project, but as we're often reminded: Management ≠ Leadership And projects need leaders.   Why?  Because people need leaders.  Humans are pack orientated creatures and we are most comfortable within a structure that supports and guides us.  Within a project the same is true.  The 'doers' usually thrive within a supporting structure that takes care of their (professional) needs and protects them from attack.  Without Developers and Testers the rest of the project team is just a lot of expensive * flesh. In a mature and capable project team there is a certain joy to be ...

If you're an Agile practitioner of any sort you will understand what I mean by Armchair Generals (if not, it may be an idea to check if you are one..). Apropos of nothing an email arrives that questions the management of your project in terms of whether it is properly 'Agile'. Feedback is, of course, a great tool.  But it must always be understood within the context of the person providing it. So when the email lands questioning the type of contingency you've built into your project or the depth of analysis performed on your requirements set, ask yourself: 1. Has the questioner spotted something you and the team have missed? It happens.  That's why independent reviews can be helpful. 2. Has the questioner misunderstood something about your project?  If so, maybe your communications weren't quite clear enough or they've missed something - it happens, we're all busy. If the questioner has understood the topic correctly and is simply disagreeing ...

A phrase Project Managers hear a lot, and one that occasionally proves to be at least partly true. As it's most often spoken rather than written, it is hard to know whether the speaker means 'agile' or 'Agile'.  I find that asking the question ('big A' Agile or 'small a' agile?) can reveal a lot about that person's knowledge of the 'Agile' world.  If you find yourself asking the people around you this question and you receive blank faces or confused responses you can be fairly certain you haven't landed in a particularly Agile organisation, rather you're somewhere that has rolled out a buzzword in the hope of improving speed of delivery. Organisations tend to fall into one of the following categories: - Comfortably Waterfall - Fine . This organisation knows how it wants to work and perhaps has reasons why they prefer to keep projects waterfall. - Waterfall but concerned they need to get on the Agile bandwagon - Confused ....

The first blog post of a new blog.  As I sit pondering what to write I'm struck by the similarities to the start of a new project. A blank sheet, some crudely formed ideas in need of refinement and a desire to get going. I sometimes think of the start of a new project as a puzzle shrouded in mist.  The pieces are all in there somewhere but someone has to dive in and start working out what will need to go where.  And we're almost never left in peace to perform this task.  Harried by our own line managers for timescales, plans, risks and what resources we need, we begin to make sense of the confusion.  All the while we are pressured by everyone to deliver as much as possible, in the shortest amount of time with the least amount of resource.  To start coding as soon as possible, but having done a thorough analysis.  To run lean, but cope with issues without extending our delivery date.  To provide estimates that are both 'quick and dirty' and als...