Wednesday 26 October 2011

Top 5 Things Learnt At IPMA World Conference


The International Project Management Association (IPMA) World Conference was held in Brisbane between the 9th and 12th of October and I was lucky enough to attend (http://www.ipma2011.com/). I attended a workshop prior to the conference over the weekend called "Young Crew", for project managers under 35. Most project managers are baby boomers, grey haired, and frankly, getting a little crusty, so the workshop hopes to encourage and inspire younger, "Gen-Y" project managers, of which I am one. The workshop was hosted by Brisbane City Council and they did a brilliant job (council did something right!). One of the speakers Jack Delosa (http://www.the-entourage.com.au/the-entourage/the-crew) spoke about leadership, mentors and the business of selling yourself, or as he put it Me Inc. The following is a list of things that I learnt or re-learnt at the conference.
  1. A mentor is not singular.
    Personally I have struggled with the idea of a mentor for some time now. My biggest misunderstanding of what a mentor is was that you had to find one and only one. How on earth are you supposed to find one person that has lived a similar life to you and is willing to spend time with you telling you their stories of success and failure? Answer: You can't. A better way is to have lots of mentors! Different mentors for different parts of your life, just like how you have friends that meet certain social needs, e.g. Billy and I both love music, but Nancy and I both love horses, together they serve my musical horse needs.
  2. Customer Expectations, better than a business case?
    A business case is great, Prince2 will tell you that, but does it cover the different types of customers and their expectations enough? The experts say no. A business case should look at customers, but often we add these as stakeholders or those requiring the outputs of the project. But what about their expectations? Six Sigma has a tool used by a process improvement team to identify all relevant elements of a process improvement project before work begins; it's called a SIPOC Diagram (http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1013&Itemid=1&Itemid=1). It asks us to consider the Suppliers (the 'S' in SIPOC) of your process, the Inputs (the 'I') to the process, the Process (the 'P') your team is improving, the Outputs (the 'O') of the process, and the Customers (the 'C') that receive the process outputs. During the presentation it was also recommended that you add 'E' to the end (forming SIPOCE) to also show the customers' expectations, e.g. non-functional requirements like speed, security, usability etc., and also their motivation for the project like, what does it mean to their everyday lives, how does it enrich them, etc. these all can give a better picture to the reasons behind a project and makes it easier for those "in the trenches" to keep focus.
  3. Earned Value Measurement
    My favourite nerdy catch phrase from my undergrad days is - "Your project plan's your map, if you don't know where you're going - you don't know where you're at!" That really stuck with me, and was probably one of the reasons for me getting into project management. But what I also (re-)learnt was that without measurements you can't tell where on the plan you are. Once again not rocket science but very easy to forget. "Achieving results by measuring progress" presented by Bram Van Oosterhout, a Software Project Manager at Toshiba outlined some very interesting techniques. At Toshiba they use Microsoft Team Foundation System 2010, their core development is mostly bespoke applications for external customers, so not all of it translates well to us but there were definitely some takeaways. Firstly, every project has the same format of project schedule. Level 1 outlines high level tasks like requirements gathering, design, development, testing, and implementation. Level 2 tasks were more project specific and relied on good estimates based on historical data and scope documents, these were created with different members of the team, i.e. a development lead help with estimating the development phase. Having every project start with the same schedule allows them to learn from their mistakes and successes, next time when they have a testing task they know that they usually take X months for a project size of Y, if the estimates are outside of this, start asking questions.
    Bram then starting showing how they calculate "function points" of tasks, not the old school function points they were more like orders of magnitude: a complex task had a high number etc. However when he started gathering data in charts he was comparing estimated hours to actual hours (all the data from TFS, and charts made using analysis services and excel) . I asked what happened to the function points? He replied that it actually didn't matter what you measured, in the end it is the trends that are important not the actual figures. This means that a large function point tasks is probably going to take longer due to that complexity, so if you compare the estimated function point oranges to the actual function point oranges, or the estimated time apples to the actual apples as long as you compare apples with apples you will see if you are on track or not.
  4. Biggest bang for your buck – which methodology should you get training in?
    Another thing that I really wanted to know was "Which methodology should I get training in". Thankfully there was a talk on exactly that. The answer was not as clear as I had hope for. The answer: All of them or none of them, but one alone is not enough. PMP (a PMBOK based method) is great for the already experience Project Manager who can fill in the gaps that are present in the methodology. Prince2 is principals based (not just documentation based as it is often flogged as), but this relies on a strong organization, preferably one with a PMO (with strong leadership) and upper management buy in.
    But neither of these will reduce poor project performance. And neither are going to work in your organisation without breaking some (or all) of the rules.
    LogFrame is another project management methodology, mostly used in construction, but is used in more projects than PMP and Prince2 combined – which is a hell of a lot. There is a simplified version called ProFrame, which, in my opinion, will be the next big thing in software development, as it can work with Agile, Waterfall, everything, but most of all is super simple for everyone to understand and implement. Proframe is a value based methodology, it asks "who, what, why, how" and relates each task to value (http://www.psaproject.com.au/about-psa/psa-methodology.aspx). There isn't much around on it yet, but give it 5 years and you'll see J.
  5. Thinking? Or Thinking!
    It may not look like it but a large part of Project Management is thinking. But it was a Project Management conference so of course they would say that, right! When was the last time you stopped and had a good old think? Tom Taylor, an exceptionally good presenter (though it may not look like it from his slides -http://www.slideshare.net/ordogroup/thinking-or-thinking-by-tom-taylor-and-ordo-group-9717949), suggested that there are 3 parts to Thinking. Part 1: A finger. Put your finger on your chin or to your temple, looks like you're thinking right? But maybe next time you are pretending to think you could try actually thinking. Part 2: A brain. Seems obvious that you need a brain to think but all too often we don't think with our brain (and no guys not what you think), we don't think we just do. You have to make time to think. Thinking for PMs (and a lot of other roles) is thinking about next week, or the week after, or two months down the track. Part 3: A highlighter. This was more about writing stuff down, but using the highlighter to focus on the most important stuff. A great tip for thinking is a to-do list, once again obvious, but when was the last time that you had a to-do list and showed it to someone else? Even better, why not have someone else write a to-do list for you? Especially if you are a manager!
The round-up:
Quote from the conference: "Einstein said 'Try not to become a man of success but rather to become a man of value.' In Project Management replace man with project – 'Try not to become a project of success but rather to become a project of value."
This was the best conference I have been on, I learnt a lot, got inspired again and met a lot of other young project managers many who are going through the same issues that I am. The next one is in Greece in 2012 - so should I start writing up my proposal now?

No comments:

Post a Comment