The world of learning technologies is fast moving it's true. I run lots of projects that move me both geographically and sometimes even philosophically. Someone asked me where I was based yesterday at a meeting in Wellington (and as I sit on my third flight in the last 20 or so hours it seems reasonable that) I replied "the cloud". But the one that has caught me a little recently and firmly given me a shunt to analyse my style of project management, is the desire for organisations to report on every minute detail along the way. Now I'm (clearly) not a dedicated project manager (what are these strange beasts anyway?), but I do manage a lot of projects; mostly of a similar nature around the implementation of Totara LMS or Moodle/Mahara. I manage projects using a kind of approach that seems logical and able to keep up with a rapidly changing environment. Until recently I never thought about what that actually was enough to give it a label, I knew it wasn't the waterfall style or Prince2 stuff I remember from my military days, but I didn't realise unwittingly that I'd stumbled on to the polar opposite of Prince; Agile project management.
To me being agile is a pretty good word for what I do so I instantly connected with it and read a little more. If you're reading this article to find out about Agile Management go and read the proper stuff or at least check out Wikipedia and find out what more edumacated people think, but if you want what I believe is at the heart of agile then read on and I'll tell you how I think it relates to your elearning projects. Agile management of my projects (yes in my speak) is all about making things run smoothly, cutting down on unnecessary stuff and perhaps most importantly of all, empowerment.
Smooth runnings; sounds a bit like that great John Candy movie Cool Runnings (hey, great may be a bit strong, but it was fun) and it almost is that laid back attitude. As a project manager the job is to not do everything and plan everything down to the nth degree, but to make everything run smoothly. The difficult part in projects is where hand-overs occur or where people have to work together. If you can facilitate these by providing the right environment and using the right tools and connecting the right people, stand back and watch the results. To me the right tools are things that entice collaboration like Dropbox and Trello (if you've not checked out this little collaborative tool, it's really great). Stuff where sharing and communication is what you do. I'm sure some of you love MS Project but I don't. It's too rigorous and not enough people have it. You have to share by saving and sending and PMs tend to lock it down in that old knowledge and power tradition which goes against everything agile. It's just a tool I know and Gantt charts and Project programs can work well, but the overcomplex chart scares me and makes the whole project feel over-prescribed to me.
Project Padding; this is the unnecessary stuff which seems to justify why so many PMs charge so much for their services. For me this is bringing in 5 people to a meeting that is about management and just needs the manager involved. Trying to pre-plan for every possible eventuality is a ridiculous concept to me. One thing about the unknown is that it tends to stay that way until choosing to reveal itself. I believe you should allow time and resource for the unknown, I believe you should be prepared for the unknown to occur, but listing all the unknowns is just something that isn't possible, so why waste masses of project time on it? I think risks and changes need to be highlighted for sure, but you can't mitigate against every possible outcome without even knowing what the risk is. Possibly the biggest project padder for me is reporting. Shock horror all round! You don't want to produce daily, weekly, monthly, hourly reports?? No, frankly I don't want to really report at all. To me the agile project reduces the need for the formal planned reports because the project runs and everyone can access a 'live' report at any time and speak to the right people. Trello is such a tool, we also use collaborative tools like Work Flow Max where clients can see what's going on with tasks and hours and all that jazz. If I update a task in Trello it sends an email to subscribers so they know. I do believe in regular catchups too, but meetings have to be the single greatest padder ever invented by businesskind. Again, meetings are a necessary part, but meet when you need to, have regular catchups that are short, sweet and to the point and if you absolutely must meet, have an agenda and stick to it and don't let the meeting degenerate.
Power to the (right) People; so to me the biggest down-side of the old-fashioned waterfall PM is that everything is set in a complex array of dependencies and responsibilities which actually defines what each person can do and then follows up with reporting, meeting and strict protocols to ensure that everyone is a slave to the almighty plan. Plans are a bit like models (not the thin otherworldly creatures on the cat-walk mind); some are good, some are not so good, but all are essentially wrong. As a physicist by training I've seen everything from Newton's laws of motion to Einstein's relativity - they're models to explain what happens in reality, but the truth is they are mathematical approximations to reality and are fundamentally flawed by the unknown. Without getting terribly deep (not my speciality obviously), a project plan is a similar hierarchical approximation of what is actually going to happen. If you accept it's 'wrong' you'll be fine. It will change and it needs to be living and breathing and you (the PM) can't control it alone, you've got to let it go and release control. To me this is where agile comes in to its own. Rather than me try and get constant updates on the bit Bob is doing, I let Bob set the original milestone and just update it as we go. Power for that part goes to Bob not to me. I need to know, but if I'm using the right approach and tools I will. Likewise I don't need reports when things are on track; I like exception reporting whereby I need to know if there's an issue. Otherwise I'll just see things happen using my tools as we go through.
Of course as a final note the best laid plans of mice and men are also known to go to rats if you don't mind me mixing my metaphors. There's only one way to handle a project that goes wrong and that's roll up your sleeves and get stuck in, throw what you can at it and don't be afraid to evaluate your own performance before getting to heavily into others... hopefully that's not something that happens too often.