IT Project Management - life on the front line

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 also perfectly accurate.