Craig Brown

Based in Melbourne. Works across SE Asia.

P: +61412406414

E: craig.brown@craigwbrown.net

T: @Brown_note

Evaluator
Better Projects Blog
@Brown_Note
Presentation decks
Events - Melbourne Scrum User Group
Events - Agile Business Analysts, Melbourne
LinkedIn
Contact

Contact

Loading,

% complete

Evaluator

Evaluator
- My business is called Evaluator.com.au. Not only do we evaluate your performance against a range of business and technology standards, we can help you grow and improve.
  
  Come and take a look at the details.
  
  Even though I am based in Melbourne we can help you anywhere in the world.
Posts

Posts

Profile
- No wonder our perception of project work is distorted. By Jon Whitty #PMFlashBlog
  
  Mar 05, 14
  
  No wonder our perception of project work is distorted.
  #PMFlashBlog – Project Management Around the World – Brisbane, Australia
  By Jon Whitty
  
  My conversations with project managers about project management began in Brisbane a number of years ago. I started a small study (which I published as: Project management artefacts and the affective emotions they evoke) where I asked project managers a simple question to which they had to pencil sketch the answer. No words were allowed. I would ask the project managers to close their eyes and remember a time they were managing a project. I then say, “Now answer this question by drawing the answer”. The question is “managing that project was like {draw}” And what they draw is most revealing. They certainly don’t draw a Gantt chart!
  
  What I discovered from this simple experiment is that our perceptions of project work is massively distorted by the various common artefacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.
  
  To explore this further consider how pictures are manipulated every day. And these images can have an enormous distorting influence on our view of the world and of ourselves.
  
  I’d like you to watch this ‘Dove Campaign’ video from start to finish. And as you watch it consider carefully the impact the final image has on both the model and you and I who encounter his picture at the bus stop.
  
  No wonder we have negative images of our own working practices.
  I’d love to be able to create a video someday to show the creation of the Gantt chart in a similar way.
  
  On the left is how project managers really experience a project. And on the right is a manipulated and distorted version of events.
  
  This is tinkering with reality in so many ways. The Gantt chart smooths out the turbulent, emotional, punctuated, messy, and unforgiving real world into smooth, modernist, calming and confident lines. The real pictures are packed with emotion, jaggedness, and non-linear relationships. None of them are even the same! If a project is anything, it’s personal and experienced personally. Yet somehow we have been duped into believing that all projects can be represented by a Gantt chart.
  
  And anyway the Gantt chart is altogether the wrong piece of art work to represent the work of a project. What it does represent it an operational production environment. If you want to know more about this then take a look at the writings of PatrickWeaver and TerryMcKenna.
  
  I think the project management practitioner community should take a long hard look at their use of Gantt charts. Don’t wait for the project management professional bodies to do it because the Gantt chart reinforces all of the ideals these bodies base their certification on.
  
  From my many conversations with practicing project managers I would say that the Gantt chart lowers their self-esteem about their work practices. And furthermore it raises the expectations of senior management to unrealistic heights.
  
  If you can’t achieve what’s on your Gantt chart, don’t you feel out of control?
  
  Perhaps we should put warnings on Gantt charts saying that the real world has been manipulated to look harmonious, ordered, and in control.
- Two great training sessions for Agile people in Melbourne
  
  Feb 12, 14
  Hey Readers, I have some Agile Goodliness for project and product managers and people who lead agile teams.
  
  I'll be pairing up with Alistair Cockburn to deliver a 2 day course on Agile Project Management on 24-25th February. Share this link around and encourage people you think will be interested to sign up.
  
  Alistair will also be leading a three day Advanced Agile Masterclass course from Tuesday 11th to march 13th as well. This is an opportunity to have your assumptions and habits challenged and for you discover new ideas and better ways of working.
  
  Both sessions are guaranteed to challenge assumptions and open new perspectives.
  
  I'd really appreciate it if you could share this across your networks so that we can get as many people across this as possible.
  Agile Project Management with Craig and Alistair
  Advanced Agile Masterclass
- A Conference Call in Real Life
  
  Jan 25, 14
  
  A Conference Call in Real Life
  
  "Have you been here the whole time?"
  
  This, is my life.
- Was Jean Luc Picard a scrum master or a product owner?
  
  Jan 18, 14
  
  I recently found myself in a Melbourne bar, chatting with a group of Agile folks. I had just met someone for the first time and as we were both business analysts as well as keen Agilists, we found plenty to chat about. At some point during the evening, we discovered we were both Trekkies and tossed around the idea that both Spock and Data must have been business analysts. We agreed to co-author a blog post on the topic, that I would still like to do, so this post is not it, but it is the result of subsequent mind wanderings on my part.
  
  The scrum guide defines the characteristics of the scrum master as someone who gives service to the product owner, the development team and the organisation: they are a servant leader who's prime directive is to serve the organisation by selflessly facilitating the success of others. The product owner's key characteristics are accountability and transparency, the product owner's prime directive is to ensure that the needs of the business are reflected in the product backlog and that the development team has all the information they need to meet those needs. This is also servant leadership, with their success being dependent on facilitating the success of others and being accountable for the decisions they make.
  
  Facilitating the retrospective...
  Jean Luc, has characteristics of both of these roles, yet my first thought was that he was definitely a product owner, responsible for carrying out the work of the business (Starfleet); accepting responsibility for not only completing the mission, but also for keeping the ship and the crew alive and well. Thinking about it a bit more, specifically how Picard goes about his duties and his demeanor, I decided that he was in fact the scrum master. Picard did not choose his missions, the product owner (perhaps Starfleet) did that, Jean Luc then set about the process of facilitating his team - the senior crew - to carry them out. Jean Luc was a leader, teacher and protector of his team; and much like many scrum masters, perfectly willing and able to roll up his sleeves and cut code if required.
  
  Peer-reviewed by Tavis Ashton-Bell (muso, composer, academic and critical thinker; the root cause of the Chess Blog series) (suss him out)
- Project Jockeys
  
  Jan 07, 14
  
  You've decided on a career change. Formerly you all were BAs, PMs, Architects or whatever, but now you've all decided to become jockeys (you know, the guys who ride horses). Your first race will be on a horse named for the thing you did the most in your old job. What is the horse's name?
  
  Mine is PowerPoint.
  
  Go.
  
  (Yes, this is absurd. Sometimes, you just need something to make the day go a little bit better and the absurd is it.)
- How would I teach it now? Some thoughts on teaching first year software engineering students.
  
  Jan 05, 14
  
  In a previous life, I used to teach an object oriented programming unit to university students. I would have been quite happy to continue doing that for the rest of my life, but for various reasons, I had to go and get a “real” job. These days I do a little part time teaching and I’m a student again myself; consequently, I still hang around university teachers quite a bit. Recently, an ex colleague from my teaching days asked me, “How would you teach it now?” His question was from the perspective of my professional and academic interest in Agile and my response was, “Well, I would teach Agile approaches from day one of first year and by third year I would run the unit as an Agile project, of course”. He questioned me a bit further and reminded me about some of the challenges this kind of teaching holds. This got me thinking about how I would teach it now and how I would respond to some of those challenges. A quick literature search reveals that there has been some research on the topic by the CS education community but not as much as I would have expected. So what follows is a combination of some of what I learned as a teacher and some of what I have learned as an IT professional.
  
  First year fundamentals;
  One of the key challenges for teachers of first year programming students is managing the range of existing skills amongst the cohort; some students have never written a line of code, whilst some may have already made money by developing and selling Apps. This means you have to be able to hold the interest of the latter, and ignite a spark of interest in the former. You know you will get a high drop-out rate, since previous programming knowledge is not required, some people will quickly find that they would rather drink bleach than learn programming and disappear. For these and other reasons, it’s really hard to do group work at this level, and most introductory courses avoid it; As a result, it’s also hard to develop an approach to lab and assignment work that results in something more than an individual portfolio of unrelated code snippets.
  These things matter, even in first year, because the ability to not only work in a team, but to work in a cross skilled, self-organising team, is as fundamental as being able to code for a software engineer and each should receive equal attention as an educational outcome. Graduates who cannot (or do not want to) work as a member of a team are, at best, significantly less employable than those who can, and at worst, a liability to their eventual colleagues and employers. (Moreno, Sanchez-Segura, Medina-Dominguez, & Carvajal, 2012) (Vivian, Falkner, & Falkner, 2013). This means that the task at hand is to find a way to give students an opportunity to develop their practical skills and to experience the synergy that results from great teamwork. Happily, since both object oriented programming (OOP) and Agile are principle driven, there is a ready-made framework which can be put to use.
  Borrowing from a very successful approach to teaching OOP principles using tools like BlueJand detailed in a 2004 evaluation; I would choose to introduce Agile principles by example. I would build on each principle week by week, introducing concepts as needed. At first year level I wouldn’t try to teach a particular methodology or approach such as scrum, but would introduce ideas where they were most appropriate. For example; introducing the idea of Personal Kanban provides a nice introduction to lean principlesand is of real practical value for students struggling to manage an undergraduate workload. Since most early programming tasks are by necessity, discreet examples of a given construct such as iteration, techniques such as user story writing could help students understand what is required of them as well as providing a very natural way in which to break down assigned programming tasks into objects and methods.
  Addressing the teamwork issue from the get-go
  In my imaginary unit, I would use the concept of pair programming to introduce students to the idea that software development is a team based activity from class one. Given the expected range of skills and experience among the cohort, the first one hour tutorial class presents as an opportunity to gather some experiential data from the students. Using this data, the teaching team would be able pair students for first lab class each pair would comprise one experienced student and one with less experience. At this level, the skills being taught are basic software development concepts, such as the use of variables, selection and iteration, depending on the tool being used, you may also have teach students how to work with an integrated development environment (IDE). Working as a pair, the students should help each other with the weaker student at the keyboard and the stronger student guiding the process. Subsequent theory sessions would then take the form of a mini retrospective on the previous week’s lab class, as well as a joint planning session for the next lab class. The pairs could be switched around so that each student had an opportunity to work with each of their colleagues over the semester. This reflects the practical workplace reality that you don’t get to choose who you work with.
  Assessment
  Assessment is another tricky area for the educator; and is usually a key item of interest from the student perspective. At first year level, students are typically assessed against each other in terms of their skill development (or other assessable criteria); consequently they have no reason to be particularly interested in helping others, or contributing to a team effort. This is where educational design meets academic administration, quality frameworks and the need for nice bell curves. Unfortunately, this puts students at odds with Agile values, where it is the competency of the team which is assessed. So whilst it makes sense to try to align the assessment approach with Agile values, this is likely to be a challenge.
  One way this can be approached is to ensure that the tutorial work described above forms a hurdle aspect of the overall assessment; the basis of the assessment should be the student’s participation in the process rather than completion of specific exercises. Marks for each tutorial component should be awarded equally to the pair and the overall marks awarded should be a worthwhile amount. The idea that pairs should change each class would go some way towards managing pairs where one student does all the work,
  Assignment work
  A common pattern for assignment work is for students to be asked to submit two or three individual programming assignments in the form of working tested software. Each assignment should build on the previous one eventually delivering a simple, but complete and working application. Generally, a student who has completed all the activities from the tutorial sessions should have had an opportunity to work with all the concepts required to complete the assignment work. Each delivery component would be marked individually, and be demonstrated to the tutorial group, allowing the practical introduction of the concepts of the sprint and iteration review, which would have been introduced as part of the lecture material.
  Tests and Exams
  Another common pattern is to require students to sit a mid-semester test and a final exam. Both the final exam and the mid semester test could be run as a coding dojo. Students could receive a brief prior and would be expected to arrive having designed a solution which they then implement within a time-box. Assessment could take the form of a review of work conducted with the tutor in order to assess student understanding, code output could be assessed via a range of automated tools including test harnesses. This approach to assessing first year programming students is not new and has been shown to work well see this paper for more information.
  Conclusion
  This essay is by no means a fully fleshed out unit design, but proposes an approach to introducing Agile concepts to beginning programming students as an integral part of how software development works. This approach could be used to build towards a third year elective in Agile software development using scrum, where tutorial groups form self organising teams and where tutors act as scrum masters with requirements of the unit representing the product owner.
  
  References
  
  Moreno, A. M., Sanchez-Segura, M.-I., Medina-Dominguez, F., & Carvajal, L. (2012). Balancing software engineering education and industrial needs. Journal of Systems and Software, 85(7), 1607-1620. doi: http://dx.doi.org/10.1016/j.jss.2012.01.060
  Vivian, R., Falkner, K., & Falkner, N. (2013). Analysing computer science students' teamwork role adoption in an online self-organised teamwork activity. Paper presented at the Proceedings of the 13th Koli Calling International Conference on Computing Education Research, Koli, Finland.
- Project managers describe their favourite challenges
  
  Jan 03, 14
  
  Knowledge Train's blog - challenges you look forward to most
- Ten lessons can Sci Fi give us about project management
  
  Dec 21, 13
  Provided in two handy posts by Intuit's Fast Pace blog.
  
  5 Insights
  5 blunders
  Entertaining and bookmarked here for posterity.
- Four Big Agile frameworks you should know
  
  Dec 16, 13
  I present to you a list of links to agile frameworks that address scale, multiple teams and complex environments.
  After reading these I realise I have my own model I can add into the mix. Unfortunately for the world I don't have much free time to write it down. Let's see of Christmas holidays give me an opportunity...
  
  Please take the time to read these frameworks which all purport to be tested successful frameworks for managing multiple teams in an agile way.
  
  Agility Path by the crew at Scrum.org and Ken Schwaber
  Disciplined Agile Delivery by Scott Ambler
  LeSS (Large Scale Scrum) by Larman and Vodde
  SAFe (Scaled Agile Framework) by
  
  Before adopting any one consider how change works and reflect on whether you want to go whole hog, and have an organisational revolution, or whether you want to take smaller steps and adapt change in an incremental and focused way. For that you could consider David Anderson's Kanban Method, or Martin Kearns and Andrea Tomasini's Agile Transitions booklet.
  
  Thanks to John Ogden for pointing me to Peter Stevens blog which has a good post on the topic.
- What is it like when it's magical
  
  Dec 05, 13
  
  I ran an open space conversation a while back asking people what it feels, looks and sounds like when you are in that special, all too infrequent place you could call "magic."
  
  This is what they came up with.
  
  Right click the image to open full size.
  Rather than take this checklist and apply it to your team it might be more useful to have a similar conversation with them. Perhaps a retrospective could be dedicated to what great teams are like to work in, and through that you could generate your own markers of good.
- Tear It Down – Rands in Repose
  
  Nov 22, 13
  
  Tear It Down – Rands in Repose
  
  Go read this. Now. I don't really have commentary because I just don't know what else I could ever add that would make it better.
- Knowledge Management in Projects – It’s stuck in the 80s
  
  Nov 08, 13
  
  Around this time last year, the UKs Association for Project Management (APM) Knowledge SIG held its first Courageous Conversation event, and I was really pleased to be part of it. Here is the video of the discussion that took place. If you watch it carefully and perhaps a couple of times, you will see the conversation really challenges our perceptions of the project management body of knowledge (BOK). Personally I thought the APM were courageous in supporting this event. The sound kicks in after 40sec.
  
  On the 3rd December this year the APM Knowledge SIG are hosting another Courageous Conversation event, and I’m sure it will be as disclosing as the previous one. It will be in Oxford this time.
  
  The topic this time is set to challenge our preconceptions about project management knowledge management, and it begins by proposing the following provoking question:
  
  Why is knowledge management (KM) in project environments 20 years behind KM in the rest of the world?
  
  I thought that in the spirit of the courageous conversation I would add my comments here, and perhaps it would help fan the flames a little.
  
  On this matter I believe that the project management (PM) professional bodies are massively to blame. But it’s not their fault! They don’t do it intentionally. It’s just a consequence of how they operate and how they see themselves operating. Knowledge management in project environments is 20 years behind knowledge management in the rest of the world, partly because of the antiquated business model of the professional bodies and partly because most projects that fail don’t kill hundreds of people as a direct consequence.
  
  Let me briefly tackle both of these points. First their business model, and second the consequences of failing projects.
  
  The Business Model of the PM Professional Bodies/Institutes: Frozen in time
  
  The business model of the various PM professional bodies or institutes such as the APM, PMI, AIPM etc. is stuck somewhere in the 1980s. Let’s not forget that each of these entities has full-time staff and premises. Their business model needs to at least support their commitment to these by generating revenue streams. The money comes in mainly through membership fees and the registration/licensing fees they charge training providers to register with them. To make the financial model work, they create levels of certification around a particular artefact in the form of their own book or project management body of knowledge or ‘BOK’.
  
  A quick response to the courageous conversation question is that the business model (centred on creating BOK artefacts that underpin revenue streams such as certification, membership, and training provider agreements) is stuck somewhere in the 1980s. Consequentially this impacts on the PM community and creates a 1980s view of KM in the project environment. This seems to be the same sort of behaviour Alan Clark generated in the late 80s/90s in the UK when he crafted the national vocational qualification framework (NVQ).
  
  Alan Clark was the Minister for employment, trade, and defence in Margaret Thatcher’s government. He fine-tuned this model and his diaries spell out the business model very well. Basically, the NVQ (national vocational qualification) was born in response to political promises to increase the qualification level in the UK workforce. The idea was to give people qualifications for the things they can already do! So let’s say you work on a production line soldering components into a printed circuit board. Realistically there are no qualifications required for doing this job, only a few hours training. But an NVQ can be created for this, and a whole workforce can be newly measured and qualified. But why would an individual want this NVQ? And why would an employer demand that their production line employees have this NVQ? Furthermore, why would anybody possibly want a qualification for a job that they can already do? These are all probably logical questions to ask. But logic goes out the window when political promises have to be kept.
  
  So Clark (or more likely his team) put together a business model to increase the number of people in the workforce with a NVQ. The business model was pretty simple. Firstly, you created some sort of badge that everybody had to have before they could apply for tenders for subcontract work from any government authority. In this particular case the badge was the ‘Investors In People’ (IIP) badge. The marketplace was given say 3 to 5 years, and within that time you had to have an IIP badge. It was a rather nice wall plaque to hang in the reception area, and a logo for your letterhead. Secondly, you defined the criteria for being awarded this badge (or levels of it) in terms of the number of employees on your staff that held a NVQ. Thirdly, you licence training organisations with the ability to award NVQs. And off the business train goes!
  
  Organisations at the top of the food chain began to appoint full-time staff to the role of managing their IIP status. NVQ performance criteria or competency standards were created by various bodies, and training organisations marched out into a NVQ hungry marketplace. The market was hungry for NVQs - If they didn’t have NVQ’d people in their workforce, they weren't able to contract with government agencies. An interesting by-product of this behaviour is that when an employee is measured against a set of competency standards (remember this is for a job they are already doing and have been doing for many years), they are found to be ‘non competent’ or ‘not yet competent’ in some areas. Of course the training organisation conducting this competency measurement inevitably has a training program that the organisation can tap into that will increase the competency level of their workforce. Training organisations have their NVQ assessors, and these assessors need to be trained and assessed. So there is a niche market for a trainer of trainers and assessor of assessors. Yes you can get an NVQ for that too!
  
  This industry (and it is an industry) is founded on the creation of an idea that there is a real need for NVQs. What if there is no real need? Does this business model sound familiar? Just replace the ‘Investors In People’ framework with any Project Management Maturity Program you wish, say P3M3 or OPM3. Then set the criteria for moving up the levels in these programs in terms of how many PRINCE2, PMP, RegPM, APMP, or IPMA Level D certified people there are in the organisation’s workforce. Finally, licence training organisations to award these certifications and deliver the necessary training, and you’ve successfully created an industry pretty much for the sake of the industry.
  
  But a significant problem with this business model is that it is anchored in the past by a physical document -the so-called body of knowledge (BOK) that has to have its contents agreed upon and sanctioned by the particular professional body. As you can imagine, the cycle for changing the contents of this BOK document is long and unwieldy. It is therefore within the interest of the project management industry not to change it. And that is how you stifle the knowledge base of the project management profession and lock it in a mode that is constantly trailing a decade or two behind where it needs to be.
  
  The unseen consequences of failing projects: they don’t fall 30,000 feet, but there are casualties
  
  If you flew on an aeroplane a 100 years ago and something small went wrong, there was a good chance you’d crash, and a good chance you’d die. Today, the commercial aviation industry is the Gold standard for safety and accident prevention. Even medical surgery is learning from them. Aviation has achieved this fantastic transition because the consequences of its failures are self-evident. No one would step in an aeroplane unless the aviation business could demonstrate that it learnt from its failures. But that is tragically not the same for project-based organisations. When projects fail, and they do so every day, hundreds of people do not die. But there are casualties. Jobs are lost, some careers are ruined, companies slowly collapse, mortgages are unpaid and stress in the workforce rises, with consequences for health, well-being and families. There are casualties when projects fail. But because the casualties and consequences are not so publicly visible, we somehow don’t feel compelled enough to figure out why and to stop repeating the behaviour that leads them to fail and to manage the knowledge our organisations gain through project work. And so, returning to the courageous conversation question, knowledge management in project environments receives little more than a passing interest.
  
  But we could do better than this. We could employ the concepts of aviation safety in our project based organisations. In the same way that every aeroplane that leaves the runway is an opportunity for the aviation business to learn how to fly planes better tomorrow; every project can be an opportunity for the project-based organisation to run better projects tomorrow. Here’s a video presentation on how to do this.
  
  The model presented is simply a conceptual model to demonstrate how knowledge about doing something is distributed across various features of our organisations. It is a network approach. And if you watched the first courageous conversation video at the top of the page, you will see that this model is a practical application of the ideas presented there.
  
  And so to some courageous concluding remarks on this matter: The business model of the project management professional bodies and institutes is not serving the project management profession well. It is simply serving itself. I have a feeling professional bodies know what to do, but somehow lack the courage, or the knowledge, or the mechanisms to do it. This morning I read on the APM Blog a posting called “listening to the profession” and there are tones of what needs to be done in there. The concept of where the BOK is needs to be challenged. The BOK is not a book, or a PDF, or an electronic web based form of a book like Wikipedia which is updated by a professional body. The body of knowledge on how to successfully and unsuccessfully deliver projects across all domains and disciplines is distributed across the community of project management practitioners in those domains and disciplines. All you need is a mechanism for asking them and tapping into that knowledge.
  
  If you are facing a challenge in your project, would you rather refer to a book of generic principles, or would you rather ask somebody who has experience in dealing what you are struggling with. All you need as a project management practitioner is a platform for asking this community, and the platform will help you find the right person to ask. This network platform should be, in my opinion, the business of the project management professional bodies. The true project management body of knowledge is a living dynamic thing, and these professional bodies should be connecting it up and making it work. It is, in a way, already doing this via its branch and chapter meetings but these physical networking devices should be brought to the front and centre of the business model. This is the sort of major courageous change the project management professional bodies and institutes need to embark on in order to shift the profession’s practice of knowledge management into a new and higher level of thinking.
- Installing Scrum the hard way - 12 months on
  
  Dec 04, 13
  Installing scrum - the hard way
  
  A year ago I joined a new team, my goal was to introduce this team to Agile methods and approaches to software development. I was looking for a challenge and an opportunity to learn and I found one.
  
  So just in case you are looking for a challenge, this is what you need if you want to install scrum and do things the hard way.
  You need a project, preferably one running at least two years late. It must be huge and complex; critical enterprise level software is good, a platform change is also good; both at once are best.
  Your project must be in an unknown state; there must not be anything that looks like a source of truth about the overall scope or the current state of the project. It's good when the business is unaware of this, because you get to tell them.
  It's particularly helpful if your project has accumulated a significant amount of technical debt, as a result of development shortcuts taken in order to meet unplanned business needs. There must not be a clear picture of the amount of TD nor must there have been any thought given to paying it off. Ideally your TD should become apparent at the least convenient moment.
  The team should not have had any training in Agile methodologies, or their associated vocabularies. Terms like “retrospective” and “backlog” should be completely foreign. The idea of a value-based approach to working should not have been broached at all.
  There should not be either budget or time for training, any training that is done must be strictly on-the-job and should not mean that the job takes any more time than the minimum required.
  There will be no visible use of story cards, burn down charts or any other form of publicly shared information radiator. These including things like the daily stand up must be kept out of sight of anyone who may find them a distraction or feels they look untidy.
  The practise of continuous integration, or the infrastructure to support it, must not be established. This means that you will need to put it in place as you go and you get to experience regular integration hell.
  Things like an established QA team or QA process and especially automated testing are a real nuisance. This deprives you of the challenge of trying to regression test an increasingly large code base by hand as well as all the fun associated with putting automation in place and ensuring your practises support it. There shouldn't be any additional budget for this either.
  It's best if your team is used to working within the confines of very clearly defined roles and are not in the habit of collaborating to decide the details of what should be built and how long it will take to build. This task should be done by someone else, it doesn't really matter who, so long as they are not a member of the development team, know very little about software development and are not distracted by things like the need to develop potentially shippable increments of the product.
  Finally, you must deliver potentially shippable increments of product, from sprint 1, whilst responding to the needs of the business by understanding their goals and challenges. You must teach the team that requirements which change as a result of these are to be welcomed as opportunities to build the right thing, meanwhile, learning the product and domain.
  Even when you have a scenario such as the one described above; if you also have a team of smart and skilled people with encyclopaedic knowledge of their domain, product and clients, as well as a management team willing to take a massive leap of faith, you can do some good things together. 12 months on, the picture is very different; every day is full of challenges, but we self-organise to meet them, we talk to each other a lot, we inspect and adapt, (informally on a continuous basis and formally on a regular basis). Best of all there is often a buzz in the air that wasn't there a year ago.
  We still have a large complex project, but we know exactly how much of the total scope we have built, and how much is yet to do. We have a release schedule and are totally unified in our commitment to meeting it.
  We regularly schedule activities such as re-factoring into our sprint plans, in order to manage our existing technical debt. We still accumulate new technical debt, but when we do so, it is the result of a strategic decision and we include its management and remediation in our planning.
  The team and the business have been gradually introduced to the values, philosophy, practises and rules of scrum. This has been done one tiny piece at a time, gently and quietly, leading by example coaching continuously and seizing every teachable moment possible. Gradually we have seen the language change and the framework and practises have become familiar and welcomed.
  We don't have a physical story wall, but we do have an electronic one that every member of the organisation has full access to. We have practised transparency through this tool by sharing our successes and failures openly and consistently.
  We have a shared repository of lightweight but permanent artefacts to support requirements and testing work. Because we know this product will outlive this team, we share responsibility for developing them and keeping these up to date.
  We do have continuous integration, as well as (for the first time recently) separate QA and UAT environments, although we still don't have fully automated testing. This is our next challenge, and we are very focused on developing the skills we need to introduce full automation. In the meantime, we are collectively a lean, mean testing machine
  The demarcation of individual roles and tasks is a distant memory. Everyone applies all the skills they have where they are needed, when they are needed.
  We work directly with the business to plan our releases at the theme level, our product backlog is about 90% estimated in story points and our detailed sprint planning is done by the team, in accordance with the rules of scrum. We are getting much better at estimating our work and breaking stories down into useful task lists.
  We delivered our first shippable increment in sprint 1, our first shippable release into our sandpit area for client feedback in March of this year and have continued to deliver two updated releases and increments every sprint and will shortly deliver our first release to go directly to client environments. Along the way, our product has been showcased to clients, has enabled us to compete for tenders and has attracted interest from new markets.
  
  Perhaps most telling on a personal level, is that I stopped keeping half an eye on the job market, quite some time ago.
- John Wheeler didn't do Death by PPT(X)
  
  Nov 05, 13
  
  Look at the chalk boards, which John Wheeler used to craft on a regular basis for his physics students. What do your walls and whiteboards communicate?
- An Agile Reading List
  
  Oct 30, 13
  Wondering what book to read next?
  
  We got a bunch of smart folks from the local agile community and asked them to bring a book to a meetup and talk about it. Check out the list below for some interesting reading ideas.
  
  Agile Estimating and Planning, Mike Cohn
  What got you here won't get you there, Marshall Goldsmith
  Black Swan, Nassim Taleb
  Directing the Agile OPrgansiation, Evan Leybourne
  Power, Jeffrey Pfeffer
  An Agile Adoption/Transforamtion guide, Michael Sahota
  Extreme Programming Installed, Jeffries, ANderson, Hendrickson
  Leading Teams; Setting the satge for great performance, Hackman
  Secrets of Consulting, Gerry Weinberg
  Quality SOftware Management, Gerry Weinberg
  Getting Real, 37 Signals
- At the completion of a particularly tough project
  
  Oct 23, 13
  
  This project manager has successfully cleared a path for the team to do great things.
- How to Prioritize User Stories
  
  Oct 16, 13
  
  Last week I ran a user group exploring How to Prioritize User Stories. I collected 54 written down explanations of what people do, and their reflections on the practices. And I have typed them up into a shared doc for you to read and reflect on.
  
  The list doesn't provide any definitive answers, but it does show a bunch of patterns and trends in thinking, so I am sharing it here.
  
  The workshop method is also described in the document. The summarized version is that we asked people to write on cards what they do today and then hand the card on to someone else, who will ask questions and add insights to the notes. Repeat n times to layer ideas on top of each other.
  
  I thought it was an interesting way to share ideas. The room was vibrant with conversation and I get the impression that many people were stimulated to go change something about the way they work.
  
  The written down notes were artifacts that recorded aspects of much richer conversations, so they don't tell the full story.
  
  If you were at the event I'd be keen to hear your thoughts in the comments on this post.
  
  The notes are here.
- What does Agile Project Management mean?
  
  Oct 15, 13
  
  Tonight in Melbourne we ran a discussion about Agile Project Managers with a bunch of Project Managers who are experienced with agile development, and a bunch of agile development people who are interested in project management. For people who view this that were not at the event I'll describe what happened and a couple of insights I came away with.
  
  Peter Lam, our facilitator broke us into two groups; project managers on one side of the room, everyone else on the other. I joined in the PM team for the discussion.
  
  The next step Peter seeded in 3 parallel questions into each group which we discussed and summarised in 15 minute rounds;
  
  1. Why is PM/Agile (depending on which group) valuable/useful?
  2. What is it about Agile/PM that is threatening?
  3. What do sponsors care about?
  
  We then broke for pizza (thanks ThoughtWorks) before coming back to one large group and putting the conversations on the whiteboard and shared key points back with the other group, shared responses to criticisms, etc
  
  Peter than facilitated a bit of synthesis to wrap us up - "So what does this all add up to?"
  
  You can check the whiteboard notes from the conversation in the session photos here.
  
  Some key points that resonated with me were that from both perspectives the failures, threats, pain from the other camp were all straw men, and the issues are all about fear and uncertainty... which brings us back to culture and conversations.
  
  Thank you Peter for a great structured conversation, that despite going for 2 hours was engaging all the way through.
- Portfolio WIP
  
  Oct 06, 13
  
  DeMarco’ assertion in the 1990’s (?) that a 5% return on investment suggest a project that shouldn’t be run. It simply isn’t worth the effort.
  
  This runs counter to the typical portfolio management approach of setting return targets within a weighted super-set of benefits. In this instance we aren’t just comparing 5% with huge benefits, we are comparing a number of competing initiatives, and some of them may have only slightly different prospects.
  
  In this instance where do you invest?
  
  I am yet to see a corporate environment that runs too few, or even an appropriate number of projects for their capacity. Most have too much going on at once, and as a result are churning and wasting energy where they don’t need to.
  
  Why not adopt WIP principle at the portfolio level? Get more done and occasionally pick the wrong order or priorities, but still... get more done?
- Bell's theorem
  
  Oct 01, 13
  
  John Bell dies in 1990 on this day. JOB was awesome because he was a challenger. Bell's theorem challenged quantum mechanics because he figured out that either things can communicate instantly across distance (ie faster than light) or they don't exist when not being observed.
  
  I started learning about quantum mechanics in the 1990s as a non scientist curious layman. It excites me and leaves me completely confounded despite years of reading up on it. Bell was able to work out some of this confusion to call out a meta pattern. That's amazing. Plus he looks like a high school teacher.
- Kelsey on "What does project management mean to me?" #PMFlashBlog
  
  Sep 25, 13
  An open letter to project managers
  
  Dear Project Managers
  
  Firstly, this is not a sermon, I'm not a follower of any particular system of religious belief, what I say is not grounded in any theology, but is an open letter, based on my own epistemologically empiricist view of the world. Secondly, I am not a project manager; my business card and CV suggest that my discipline is business analysis, so I will begin by setting out the background material that has informed this post. To provide some context, after a quick count up, I have worked on (roughly) 30 software development projects over 20 or so years. Mostly my role has been business analyst, these days team member is the best description. I have often needed to perform duties that could be described as project management, but I have never worn your hat or walked in your shoes. I have, however, had the opportunity to work closely with quite a few of you over the years, so it is from this perspective that this post is written.
  
  My background as a business analyst could best be described as traditional and formal. I cut my BA teeth on, business requirements specifications, functional specifications and traceability matrices. My place in the software project world was defined by a line, (or several) on your Gantt chart and my definition of done, was met when 100 percent complete and a milestone due date coincided. Then I was off your project and ready to meet my next PM and do it all again. In the meantime, perfect software would be churned out by a development team, tested by a QA team and delivered as a fait a complet to delighted customers.
  
  This scenario assumes that the business is able (in advance) to accurately define the right functionality for a given product, such that the time and resources required to develop this functionality can be specified. Further, it is assumed that it is possible to accurately record this information in a plan and track progress against that plan. This leads to the underlying premise of project management, that the effort required to deliver a project is reliably estimable regardless of the product or service to be delivered.
  
  The result of the assumptions described above is that software development project manager has an unenviable task. The essay, The Tower of Babel Did Not Fail (Adamczyk & Hafiz, 2010) discusses the challenges associated with attempting to succeed at something, which (historical evidence suggests (Larman & Basili, 2003) has around a 70% chance of failure. This essay argues that software development projects are distinctly different to civil engineering projects in several fundamental ways. Some of the key differences are that there are few known or fixed variables, such as the strength of materials or the impact of gravity and that much of what is developed is completely novel to those developing it. In particular, software products are expected to be modifiable, scalable and reliable, (over an unspecified period of time) regardless of the domain and environment in which they are asked to operate.
  
  In response to the challenges described above, the development of iterative and incremental approaches to software development (Larman & Basili, 2003)and the development of formal software development governance (SDG) models (Bannerman, 2009) have been credited with some modest improvements to the dismal success rates of software development projects. More recently however, in his discussion of the 2012 Standish, CHAOS report ("The Standish Group," 2013) Mike Cohn, claims that use of Agile methodologies (rather than those classed as iterative and incremental) offer even greater advantages, with reported success rates for Agile software development projects of up to 42% (Cohn, 2013). This has led to an increasing number of organisations experimenting with or formally adopting Agile approaches to the implementation of software development projects. Particularly in the last 3 years, Agile approaches, tools and techniques have made their way, to some extent or another, into just about every software development project, commercial or otherwise. If you haven’t come across it yet, it is probable that you will.
  
  If your discipline happens to be software development, you are well served; much of the discussion around Agile has been focused on the actual process of designing, coding and testing software, that’s where most adoptions start and where there is the most expertise. However, if your discipline is business analysis or project management the story is different. Not only is your role not described in the Agile manifesto, there are no practices to support it either. This means, that for those of us who find ourselves working on a project using scrum, Kanban, XP or one of many other Agile methodologies we need to reinvent and rethink our role. Having been a little way down this road now, one of the key lessons for me has been that as a member of an Agile team I value different things from my colleagues than I did before and that I have different expectations of my project manager.
  
  Whilst the set of principles and values, which underlie Agile, are simple, fully adopting them is not. This is because Agile is much more than a set of practices; it is a philosophical lens, through which to see and think about the work we do. Making the shift from the thinking style required by plan based approaches to project management to Agile, change driven, approaches has a far greater impact on the success of otherwise of Agile project than the adoption of a daily standup. This is where the strengths and skill set of the software project manager can really make a difference if you do the following things;
  
    Learn about Agile, by this I mean, get to know the underlying philosophical theory and support your team in their attempts to internalise it. Understand that Agile requires more discipline and more rigor than a traditional approach primarily because it demands transparency and accountability. You actually have to produce some software at the end of each iteration/sprint; you really cannot ship a document.
    Hire an Agile coach, listen to them and let them do their job, which is to help the team to become high performing and self organising. This will mean that at a minimum you can stop spending your time trying to manage other people's (developers/testers/BA's) time.
  Understand the purpose of each practice, respect it, and use your skills to facilitate the team's ability to apply their practices, You can only gain from doing this, for example attending the daily standup (in a scrum team) or facilitating the use of a shared information radiator means you will have a far better understanding of exactly where your project is at.
  Teach the business about Agile, if this is their first Agile project, they will see it as inherently risky. Understand that the business has probably learned to take comfort from a progress marker on a Gantt chart and will take time to understand that a demonstration of working software is actually more useful as a measure of progress.
    Think about how you can serve the team by removing obstacles and bottlenecks; resourcing to support concepts like continuous integration and automated testing, reduce your risk significantly.
  Hire intelligently, think about your team as a complex adaptive system, new resources need to either understand Agile or be willing to develop their understanding of Agile.
    Ferociously protect your constraints, if for example you have a team member with a critical skill set, do not allow that person to be pulled in a million and one directions as every project's goto girl/guy.
     Have a shared, respected and immutable definition of done
  Be prepared to roll up your sleeves and pitch in, Agile teams do not have demarcation disputes.
  
  There are a couple of important don'ts
  
    Don't hijack, or allow someone else to hijack a sprint and then complain when the team does not meet it's commitment.
    Don't tolerate an individual who undermines what the team is trying to achieve, no matter how senior ("special") they are.
  Don't attempt to use team velocity as a measure of performance or a comparison between teams .
  
  As a project manager on an Agile software development project, your job is not command and control, but is truly that of the servant leader, you play a key role as a facilitator between the team and business and are an integral enabler of the team's success. If you are lucky you will be able to keep a team together over a long project or over multiple projects; when you have sprinted 20 or 30 times with the same group of people, you develop a sense of community, commitment and mutual respect which transcends the mundane and makes the process and the product better for everyone.
  
  Yours sincerely
  
  The business analyst
  
  References
  
  Adamczyk, P., & Hafiz, M. (2010). The Tower of Babel did not fail. Paper presented at the Proceedings of the ACM international conference on Object oriented programming systems languages and applications, Reno/Tahoe, Nevada, USA
  
  Bannerman, P. L. (2009, 17-17 May 2009). Software development governance: A meta-management perspective. Paper presented at the Software Development Governance, 2009. SDG '09. ICSE Workshop on.
  
  Cohn, M. (2013). Mountain Goat Software.   Retrieved 23/05, 2013, from http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall
  
  Larman, C., & Basili, V. R. (2003). Iterative and incremental developments. a brief history. Computer, 36(6), 47-56. doi: 10.1109/mc.2003.1204375
  
  The Standish Group. (2013).   Retrieved 03/06/2013, 2013, from http://blog.standishgroup.com/
- Jon on "What does project management mean to me?" #PMFlashBlog
  
  Sep 25, 13
  
  I honestly have mixed feelings about project management, the very idea of projects, and the role we now call project manager. They truly are a great jumble of meanings, emotions, opinions, and mobilising forces. Overall they probably are ‘Goods’ in Aristotelian ways. What I mean by that is that through the practice of project management individual project managers feel an increased sense of happiness and achievement, and so do, generally speaking, the stakeholders of projects. Anyway I thought I would take this opportunity to muse a little on the powerful influences of projects, their management, and their managers, and what this all means to me.
  
  On the project
  Evolutionary science could describe the concept or idea of a project as a ‘weak force’. In and of itself the concept of a project is a small matter. But when you play it out in the minds of a phenomenally large amount of people it has a big impact. None of us really truly believes that there is a thing called a project. It’s just a way of thinking about work that we can’t or choose not to approach in an operational way. It’s a way of thinking about work that we don’t want to, or can’t, put on a production line. The project is a ‘thinking algorithm’ about work. But just because you can’t hit it with a hammer doesn’t mean it doesn’t exist. Consider the metaphor of an invisible cord which is often used by teachers of ballet to correct the posture of a young dancer. The dancer is told to imagine an invisible cord running up through their body, from their toes, out through the top of their head, and up to the sky! Consequently, the dancer’s behaviour is changed and their posture is considerably improved. However, both teacher and dancer know that the cord does not really exist. The invisible cord is just a ‘thinking device’ or ‘thinking tool’, which when used produces behaviour that proves to be beneficial to the dancer and the teacher. Imagine how ridiculous it would be to argue and defend the cord’s various dimensions and parameters. We wouldn't argue about the dimensions and parameters projects and complex projects and agile projects. We wouldn't set up a whole discipline about how to manage invisible cords… I mean projects, would we?
  
  Nevertheless, the concept of a project does generate behaviour of enormous proportions. If millions of people run this thinking algorithm in their heads it literally begins to change the shape of our modern world. The advent of steam allowed the factory to move away from the river system. The concept of the production line and its optimisation revolutionised manufacturing and production. And couple all this with the microprocessor and organisations have been able to break free of all physical bounds. The production environment is no longer in one geographical space. It can be in many, and it can be mobile. The concept of ‘the project’ has played a significant role in the liberation of production. Steam released us from the waterways. Projects have released us from the production line. However, it is this last point that creates a tension in manufacturing and production which is difficult to grapple with. Resolving the tension is perhaps not the solution, whereas learning to live with it is. More about tensions shortly.
  
  On project management
  A very simple rationale underpins project management. It stems from the thought that project work cannot look after itself, therefore it needs managing. At a superficial level project management is the application of a bunch of tools that have been adapted from other disciplines to apply to a body of work that can’t quite be handled in an operational manner. More sophisticatedly, projects coupled with project management, are a way for an organisation to structure itself so that it can flexibly adapt to its environment; speculate with new products or services, or make improvements to the current production capability. But with this flexibility comes a lack of control.
  
  Project management has also given rise to the role of the project manager. After all, who else will apply the project management tools and attempt to manage the project. And thus a new niche discipline is created; the managers of projects.
  
  On the project manager
  The lot of a project manager is not an easy one. They have more in common with project managers in other organisations than they do with employees in their own. They share common burdens. They don’t completely fit in with the organisational structure, but they are absolutely and completely necessary. To a certain extent their work is unplannable and hard to control, but they are expected to plan and be in control. They work in a world of largely guessed at estimates, yet they are held accountable to budgets. They can be paid good money, but work is not always guaranteed. They can be deemed as responsible, but often have little decision-making power. And when they are able to make decisions, how should the project manager know what the right or good decision is? What decision-making framework should they use? Should it be what’s right for the project, or what’s right for the organisation, or what’s right for the client, or what’s right for themself and their career? Should it be a combination of these or just one? The project manager lives in a world of tensions and dilemmas.
  
  And so to tensions
  For the modern organisation to be fit to survive its environment it needs to hold together as a cohesive group yet it also needs to be flexible enough to respond and change with the various competitive pressures it faces. It needs strong governance, but not too strong. It needs structure, but not too much structure. It needs to be stable, but not too stable. It needs to present as confident, visionary, and self-assured, but it must be able to renege on its vision and plans if needs must and its survival is threatened. And where does the project manager live? They live right in the middle of all this tension. They are pulled between the fruitful opportunities of serendipity on the project front-line and the powerful gravitational like forces of the structures of corporate governance. But let us not forget that project managers like it.
  
  So to me true project management is an individual response to the taunting forces in modern work. And it is the project manager's way of handling the tensions as they all have somewhat unconquerable souls.
- Craig on "What does project management mean to me?" #PMFlashBlog
  
  Sep 25, 13
  
  Identity, power and relationships matter. Project management is a multifaceted tool that can help you manage yours.
  
  I have been blogging on project management since - holy cow - 2005. You would think by now that I would have this question answered. And once upon a time I did. And then I learned more and I didn’t again. And then I learned more, and I was able to answer the question again. And today I am not so sure. The lessons are never ending, but there are probably a few fundamental truths at the heart of it.
  
  Let me start with looking at what a project manager is.
  
  Am I a project manager? I am a person with multiple aspects to my identity. There is work me, parent me, partner me, son me, friend me, blogger me, chaotic social networker me and more. Project management is one aspect of my identity. I do it as a job sometimes, and sometimes I do it as an activity within a different job role. Sometimes, I am not a project manager at all.
  
  So I might be a project manager, depending on what I am doing and where I am when you ask me. Or I might not. I suspect the same is true for you.
  
  Job roles, and the related characteristics of identity are an award of organisational power. It’s pretty good to have a power job title when you want to influence other people with their identity wrapped up in their ideas of power and control at work. It gets you access to other people in power, particularly the ones that manage the status quo.
  
  Project management can bring power, yes. But not on it’s own. You have to step up and take it. You have to be there. You have to have a point of view. You need confidence in yourself with these people or you’ll get dismissed and probably never be able to recover until you change companies or departments.
  
  Fortunately project management gives you a toolbox of things to be an expert in, which people have come to value over the years. I am not sure whether people value these competencies for any universal reason, but the project management industry has done a good job of selling the benefits of bringing in a project manager who does formal, recognized Project Management Things.
  
  For a while I suspected the fundamental value of a project manager was the ability to manage forward estimates. We do this differently from other people. We apply disciplined and arcane planning and estimating practices that factor in things like past performance, uncertainty and risk.
  
  This is a particular differentiation from a normal 'non-project' manager, because things like managing, processes, and products are “normal” management activities. I learned that when I read the PMBOK years ago. Normal management was out of scope of the Body of Knowledge, because it was standing apart from normal management. Not because normal management skills such as listening to staff and helping them be successful were not things to be done, but because they were considered ‘default’ behaviors.
  
  Paying attention to people, the ones on the team, and the clients and customers we work for, is our main job. It’s not an explicit part of the project manager lore, but it is the most important thing we do at work. As people doing work with people for other people, we need to improve our skills in listening and understanding. While that’s not exclusive to project management it is tied inextricably to what we do. How can we be successful in the work we do without paying attention to people.
  
  As project managers, we need to understand what motivates our staff and what our clients and customer value. To do that we need to know them, to spend time with them and to understand them. A critically important idea is that we need to learn to connect with our customers and understand them better.
  
  The other, lesser, but still important parts of project management are to bring discipline and technique to planning, forecasting and managing uncertainty while the project is underway. These are useful things, but not sufficient in the context that matters; providing value for our clients. And yet, they are things you must excel at if you are to call yourself a project manager.
  
  By building these planning and managing skills, you earn yourself a place in the discussions about what does matter to the organisation and to it’s customers. You will be invited to bring project management competencies and knowledge to the steering teams and client discussions that are highly valued and affect the strategy of your company. You will also participate as a human, not just a role. You will have the opportunity to bring your other knowledge and experience to the discussions. You will influence their decisions about what to do and how it should be done on both your and other projects. You will get to use your influence and place in these discussions to help the team be successful, by providing advice to partners and clients or brokering understanding across networks of people involved in the project.
  
  What does success look like? Success comes before the end of the project, but not at the beginning, although you might have early clues about your chances. For me the beginning of a project provides an opportunity to feel success but you won’t be sure.
  
  You know that frantic insanity that Hunter S Thompson opens Fear and Loathing in Las Vegas? That sense of overwhelming paranoia? Anything and everything could go wrong, and you don’t know where the problems are going to start, or where they are going to come from. To me this is exhilarating and exciting. And important. It gives you urgency and mission. You just don’t know whether you’ll be able to beat the system or not, but you know you have to get started… now.
  
  After a while, you knock out some wins and the project starts to build a rhythm and produce a set of valued outcomes. You’ll have some credibility with your clients and partners. You’ll have tested the delivery environment and understand the your chances of success and the various risks that will get in your way. If project management can be likened to a game, you’ll feel like you know the rules.
  
  Success manifests in the people around you; the team are confident and regarded as doing a good job. The client and stakeholders feel informed and included, and part of a broader team. Success is palpable. Confidence is in the air. There's a noticeable lack of stress and worry. People are talking about value, and opportunities rather than risks and problems. You’ll know it when your there. You’ll feel it.
  
  And when you consistently nail your projects this way you are ready to tackle the next level - bigger, tougher environments, more complex problems. And you start afresh, knowing that success is not an indicator of who you are, but a score in a game. And you’ll have the quiet confidence to go to work on these problems because you are constantly testing and challenging yourself to grow and be a better player.
  
  You know that project performance doesn't mean you, as a person, are a success or failure. Your value as a person is something else. Your projects all deliver value in one form or another. Your job becomes one of generating mutual understanding about value and options rather than rushing to a deadline. Your personal successes will be measured in the relationships you form with people, with the value you see created from bringing people together and in helping the world around you navigate change.
- My PMOZ workshop TL;DR
  
  Sep 17, 13
  I stole most of this from Doc Cockburn.
  Sport and military metaphors don't help.
  Let's dance.
  Talk to each other as individuals first
  That can scale
  Think about what helps us collaborate. (Here are some ideas to get you started.)
  Tell stories about collaboration
  Look for the patterns and discuss
  Now hug your neighbours and thank them.
  Yes. I used a PPT Deck
- Project Management #Flashblog
  
  Sep 16, 13
  
  If you are interested in developing yourself into a project manager this month brings a great opportunity to get some insights from people who have done it already.
  
  Firstly, bookmark Shim Marom's blog and secondly black out your calendar on the 25-26th of this month. You're going to need both days. On the 25th Shim will be publishing a list of over 50 project management bloggers who are going to all post on what it means to be a project manager.
  
  This is a list of seasoned, experienced reflective practitioners. You'll have access to a wide range of well read and informed people reflecting on what it means to manage projects, and to be a project manager. This is going to be an exceptional list full of exceptional PM bloggers sharing their ideas.
  
  Stay tuned.
Tweets

Tweets

Profile
- Great use of horizontal scrolling http://t.co/G3VA3C8hEc The solar system to scale
  
  Mar 07, 14 from TweetDeck Reply, Retweet, Favorite
- RT @embilbie: "Pop Will Eat Itself ~ Not Now James, We're Busy" https://t.co/NW4yKv9l76
  
  Mar 07, 14 from Twitter for Android Reply, Retweet, Favorite
- here comes the long weekend...https://t.co/lh2WGT2Ksl
  
  Mar 07, 14 from TweetDeck Reply, Retweet, Favorite
- @SimonCockayne still it's early thin slice
  
  Mar 06, 14 from Twitter for Android in reply to SimonCockayne Reply, Retweet, Favorite
- @SimonCockayne it's probably on his blog @neil_killick
  
  Mar 06, 14 from Twitter for Android in reply to SimonCockayne Reply, Retweet, Favorite
- @neil_killick I set em up Ypu hit em out of the park @RMcKergow
  
  Mar 06, 14 from Twitter for Android in reply to neil_killick Reply, Retweet, Favorite
- Become an ICT manager for a good cause http://t.co/LxkXRzZUTw
  
  Mar 06, 14 from LinkedIn Reply, Retweet, Favorite
- @neil_killick @RMcKergow just pointing to the books good sir. When is your due by the way?
  
  Mar 06, 14 from Twitter for Android in reply to neil_killick Reply, Retweet, Favorite
- @RMcKergow reinertsen
  
  Mar 06, 14 from Twitter for Android in reply to RMcKergow Reply, Retweet, Favorite
- @RMcKergow take a look at books by David Anderson or Don Reinerstien
  
  Mar 06, 14 from Twitter for Android in reply to RMcKergow Reply, Retweet, Favorite
- Interesting comments appearing on this post - http://t.co/DwPvJNtU7g #pmot #baot
  
  Mar 06, 14 from TweetDeck Reply, Retweet, Favorite
- We had @TotherAlistair in the office this week. If you want more of his Advanced Agile content go here https://t.co/jeua9NnhSU
  
  Mar 06, 14 from TweetDeck Reply, Retweet, Favorite
- Know a woman who codes? http://t.co/hqIFBxR4dW
  
  Mar 05, 14 from Twitter for Android Reply, Retweet, Favorite
- http://t.co/DwPvJNtU7g #pmot #baot
  
  Mar 04, 14 from twitterfeed Reply, Retweet, Favorite
- @aahoogendoorn @DerailleurAgile Ypu should drop ie in there
  
  Mar 03, 14 from Twitter for Android in reply to aahoogendoorn Reply, Retweet, Favorite
- RT @aahoogendoorn: The reason why the Microsoft Excel logo starts with an X. http://t.co/D4GwHayZPy
  
  Mar 03, 14 from Twitter for Android Reply, Retweet, Favorite
- @rachelcdavies @MartinBurnsSV @RonJeffries @PapaChrisMatts @jamieosh thx. Feels like a type of Mgt. Maybe (soft) systems engineering
  
  Mar 03, 14 from Twitter for Android in reply to rachelcdavies Reply, Retweet, Favorite
- @rachelcdavies @MartinBurnsSV @RonJeffries @PapaChrisMatts @jamieosh no accountability for an outcome?
  
  Mar 03, 14 from Twitter for Android in reply to rachelcdavies Reply, Retweet, Favorite
- @hemppah @duarte_vasco @Kurt_Haeusler no its about gsd
  
  Mar 03, 14 from Twitter for Android in reply to hemppah Reply, Retweet, Favorite
- @duarte_vasco @Kurt_Haeusler @hemppah this
  
  Mar 03, 14 from Twitter for Android in reply to duarte_vasco Reply, Retweet, Favorite
Posts

Posts

Feed
- Collaboration: Cockburn's Dance of Contribution in a Workshop
  
  Jun 04, 13
  
  This is a presentation which accompanies a workshop on Alistair’s "Collaboration; The dance of Contribution" article. You can read the article here: http://alistair.cockburn.us/Collaboration%3A+the+dance+of+contribution The workshop includes two games as well as a description of what leadership behaviours matter when you move from a compliant or merely co-operative culture to a collaborative one.
- Melbourne agile and scrum sig slides v01-00
  
  Sep 26, 12
  
  Presentation by John Giles to Melbourne Scrum User group. From 26 Sept 2012
- Starting projects
  
  Apr 05, 12
- Story mapping introduction short version
  
  Feb 17, 12
- Agile values
  
  Oct 04, 11
  
  We ran a lunchtime session talking about values and how they underpin the way we work. The session closed out with a whiteboard exercise which is described on the last page of this deck. If you use this I’d appreciate your sharing your experiences and feedback via the comments or by email. Thanks!
- Requirements & scope
  
  Aug 07, 11
  
  I gave this talk at PMOZ last week.
- Requirements = Scope
  
  Jun 02, 11
  
  This is a short introduction presentation for the PMOZ conference in Sydney later this year.
- Requirements = Scope, BA World Bengaluru 2011
  
  May 29, 11
  
  In May 2011 I presented this discussion of why project scope is driven by requirements, how requirements change is inevitable, and how that makes good project estimates very difficult. I then present one useful technique for managing this challenge.
- Starting a new project using Scrum
  
  Apr 12, 11
  
  I gave this to the Melbourne Scrum Users Group. It was an interesting group with a few experience scrum users and many inexperienced people via the ACS, so the talk had to accommodate some Scrum 101 stuff, and went longer than planned with me talking for a bit over an hour. In the end it went well, and I hope I get some feedback from the audience via the meetup site and ACS website.
- Ba tips: the complexity of workshops
  
  Jan 22, 11
  
  When Business Analysts take their analysis and recommendations to stakeholders, we often use workshops. There is a trap in the workshop. You can only fit so much communica
- Scrum 18 months later
  
  Aug 05, 10
  
  Where are we 18 months after the teams adopted scrum. Where do we want to go?
- How Business Analysts Can Re Invent Themselves For An Agile World
  
  Sep 23, 09
  
  a presentation on how a business analyst can fit themselves into an agile/scrum project. Comments very welcome.
- Business Analyst As Product Owner
  
  Jul 03, 09
- Kano Analysis and Software Requrements
  
  Jun 13, 09
  
  Using Kano Analysis to prioritise Business Requirements Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders.
- How To Assess Project Proposals
  
  Feb 19, 09
  
  Some notes on how to assess a project brief or business case proposal. Don’t buy what you hear on face value.
- How To Review Software Requirements
  
  Feb 12, 09
  
  A guide on how to review and give feedback to business requirements documents for software projects.
- Software Project Methods
  
  Jan 16, 09
  
  A summary of the more popular software develpment processes and methods.
- Invest In Good User Stories
  
  Oct 10, 08
  
  A little information on writing good user stories
- The Project Management Process - Week 11 Contemporary Issues
  
  Oct 07, 08
  
  Wrapping up the intor to project management series with a skim across some conemparary issues.
- Partnerships And Goal Alignment
  
  Oct 04, 08
  
  Some thoughts on the challenges of goal alignment between consultants and clients
Posts

Posts

Feed
- Scrum Monthly Meet-up
  
  Feb 19, 14
  
  Melbourne Agile and Scrum User Group
  
  Lyssa Adkins and Michael Spayd established The Agile Coaching Institute in 2010, with the aim of improving the practice of Agile coaching everywhere. Their efforts have resulted in the development of ICAgile learning objectives (for the coach learning path), a framework for viewing and developing in the agile coaching role.
  
  Having seen Lyssa and Michael present this at YOW! last year, James Holmes is ready to spread the word. He'll (in his words):
  
  ". . . present the framework, introducing the different areas in which Agile coaching can operate. Then I'll get people to work in groups to figure out what kind of coach they are looking for or what kind of coach they are. Finally we can do some coach/team speed dating to see if we can send people home with a good coaching match."
  
  If you are looking to engage a coach, here's a chance to better understand the role and what you should be looking for with your organisation (needs, culture, size etc) in mind.
  
  If you're a coach, heres a chance for you to learn more about evaluating your own skills and strengths, and find resources for improving your craft.
  Melbourne - Australia
  Wednesday, March 26 at 6:00 PM
  
  Attending: 43
  
  Details: http://www.meetup.com/scrum-12/events/142133502/
- Scrum Monthly Meet-up
  
  Jan 09, 14
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  Melbourne - Australia
  Wednesday, April 30 at 6:00 PM
  
  Attending: 8
  
  Details: http://www.meetup.com/scrum-12/events/147672012/
- Adapting to the team. From agile to lean to lean startup.
  
  Feb 24, 14
  
  Melbourne Agile and Scrum User Group
  
  Adapting to the team. From agile to lean to lean startup.
  Hawthorn - Australia
  Wednesday, May 28 at 6:00 PM
  
  Attending: 15
  
  Details: http://www.meetup.com/scrum-12/events/147672322/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  Melbourne - Australia
  Wednesday, June 25 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/scrum-12/events/166102122/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  Melbourne - Australia
  Wednesday, July 30 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/scrum-12/events/148222312/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  Melbourne - Australia
  Wednesday, August 27 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/scrum-12/events/166390872/
- Scrum Monthly Meet-up
  
  Jan 09, 14
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  Melbourne - Australia
  Wednesday, September 24 at 6:00 PM
  
  Attending: 1
  
  Details: http://www.meetup.com/scrum-12/events/159559552/
Posts

Posts

Feed
- Integrating BA, UX and others with Agile Engineering teams
  
  Dec 09, 13
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Teams continue to struggle to integrate UX and Business Analysis practices into agile engineering teams.
  
  Tonight we explore why this happens and look at a variety of approaches you can use to better connect your teams.
  
  Melbourne - Australia
  Tuesday, March 11 at 6:00 PM
  
  Attending: 70
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/127358752/
- How to jazz up your Retros
  
  Jan 06, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Hi everyone,
  
  I'd like to tackle the topic of Retrospectives and how you can jazz them up.
  
  Retrospectives are fairly common among Agile teams, but have you noticed a lack of interest lately when using the same, old format:
  •What worked well?
  •What didn’t work so well?
  •What still puzzles me?
  
  The aim of this presentation is to bring back to life the retrospective with a number of different techniques and approaches that you can take away. By jazzing up your retros, you'll be able to maintain interest in this important ceremony and gain new insights from your team.
  
  - Ryan McKergow
  Melbourne - Australia
  Tuesday, April 8 at 6:00 PM
  
  Attending: 38
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/146845272/
- The Roles and Attributes of an Agile BA
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  1. Role, Scope, Diversity
  
  • Role, not Title
  
  • VM-BA and Other roles
  
  • Adapting to context
  
  2. Attributes of the role;
  
  • Bridge, not ferry
  
  • Keeper of responsible decicions
  
  • Big Picture View
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  
  Melbourne - Australia
  Tuesday, May 13 at 6:00 PM
  
  Attending: 50
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/146845242/
- The Personal Attributes of Agile BAs
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Attributes of the people that perform the role! This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  1. Thinking Skills
  
  • Critical Thinking
  
  • Systems Thinking
  
  • Comfortable Ambiguity
  
  Flexibility
  
  2. Behaviours
  
  • Ask tough questions
  
  • Show, Don't tell
  
  • Influence, not power
  
  • Give the bad news
  
  • Stand up for the value
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  Melbourne - Australia
  Tuesday, June 10 at 6:00 PM
  
  Attending: 22
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/147672412/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, July 8 at 6:00 PM
  
  Attending: 5
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/148222242/
- Agile Discovery
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Discovery techniques and practices. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  • Understanding Stakeholders
  
  • Think like a customer
  
  • User needs and habits
  
  • Bridge understanding gaps
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  
  Melbourne - Australia
  Tuesday, August 12 at 6:00 PM
  
  Attending: 11
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159139792/
- Agile Analysis
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Discovery techniques and practices. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  • Amount of context needed
  
  • Type of context needed
  
  • Seeing the whole
  
  • Maintain value at all levels
  
  • Know the contraints
  
  • Determine risk
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  Melbourne - Australia
  Tuesday, September 9 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159139862/
- Agile Delivery
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  1. Feedback
  
  • Receiving feedback
  
  • Communicate with examples
  
  2. Managing Artifacts
  
  • Defining done
  
  • Progressive elaboration
  
  • Understanding what is do-able
  
  • Avoiding waste
  
  • Assess and validate delivered value
  
  • Prioritize for value
  
  • Slicing and chopping
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  
  Melbourne - Australia
  Tuesday, October 14 at 6:00 PM
  
  Attending: 3
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140152/
- Anti-Patterns and Pitfalls
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Tonight you'll be continuing the design of a framework for personal development.
  
  The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
  
  We will be breaking into groups of 4-5 and working through the following sub-topics.
  
  1. What we can control
  
  2. What is beyond our control
  
  We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
  
  The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
  
  We will collect your content and over the year publish a shared framework for a personal development plan or training course.
  
  Hosted by Shadi Zandi and Craig Brown
  
  ICAgile reference
  
  http://icagile.com/fi...
  
  Melbourne - Australia
  Tuesday, November 11 at 6:00 PM
  
  Attending: 3
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140342/
- Reviewing our work for the year
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  This month we review the development plans we collectively work on during the year and map it back to the ICAgile framework.
  
  We'll also explore how we can deploy the course to our peers and network.
  
  Hosted by Shadi and Craig
  
  ICAgile ref: http://icagile.com/fi...
  Melbourne - Australia
  Tuesday, December 9 at 6:00 PM
  
  Attending: 3
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140562/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jan 07, 14
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, May 12 at 6:00 PM
  
  Attending: 1
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140552/
Info

Info

Profile
- Craig Brown
  
  Team member at Aconex
  
  Management Consulting | Melbourne Area, Australia, AU
  
  Summary
  
  Craig’s roles over the past 15 years have involved leading project management teams, projects and programmes, consulting, training and coaching in a variety of aspects of project delivery. Most recently Craig was a program manager on Telstra’s Customer Advocacy journey, working with culture change, Net Promoter Scores, and lean-style customer centred process improvements.
  
  Apart from the disciplines of project and portfolio management Craig is also an Agile and Lean enthusiast with a focus on the collaboration and cultivation aspects of agile practices and methods. Craig runs the Melbourne Scrum User group and also runs meetup groups for Agile business analysis and agile project managers where he helps people navigate their way from traditional roles and thinking to modern ones.
  
  Craig also co-created the LAST conference which is a low cost community driven conference focusing on lean, agile and systems thinking.
  
  Experience
  - Sept 2013 - Present
    Senior Engineering Manager / Aconex
  - Jul 2013 - Present
    Chief Community Builder / Tabar
    
    Bringing people together to do great work together.
    
    In this capacity I curate LAST Conference, Deliver Management 3.0 and other Agile training, run Agile community of practice groups and help teams improve the way they work.
  - Jan 2008 - Present
    Director / Evaluator.com.au
    
    Consulting business that helps you understand how to improve your project and technology performance.
  - Jul 2012 - Aug 2012
    Program Manager, Customer Advocacy / Telstra
    
    Responsible for
    - Coaching executives and general management on the meaning and application of customer advocacy, lean and agile practices.
    - Portfolio management across Telstra Operations Customer Advocacy program; PMO across both capital and operational programmes targeting improved customer experiences
    - Integrating multiple PMOs across Operation’s lines of business into one Advocacy Portfolio.
    - Hands on program coaching on top 6 priority Customer Advocacy programs.
  - Jul 2011 - Jul 2012
    Head of Project Management & Assurance / Swinburne University of Technology
    
    In this role I had three main responsibilities:
    
    I managed the project delivery capability at Swinburne's IT department. This includes project managers, business analysts, quality analysts and testers.
    
    I managed the IT project Portfolio and PMO.
    
    I was also engaged in working with business partners to the IT department to help increase overall project and product delivery capability.
  - Jul 2011 - Jun 2012
    Occasional Agile Trainer @ Telstra / Accenture
    
    Participating in the agile adoption at Australia's largest telco.
  - Oct 2010 - Jun 2011
    Consultant / Business Analysts Pty Ltd
    
    I worked with organisations to increase their project capability through systematic improvements to process, systems and tools. I also coach with people on BA and PM techniques and methods and also help out on projects at a practical level.
  - May 2008 - Nov 2010
    Program Manager / Workcover NSW
    
    Managing strategic program updating business models, replacing legacy IT systems with both in house and vendor delivered solutions, and implementing Scrum along the way.
  - Mar 2008 - Jul 2010
    Lecturer / Melbourne Institute of Technology
    
    Lecturer in Project Management to Masters degree students.
  - Apr 2008 - May 2008
    Consultant / St George Bank
    
    Project recovery and strategy work.
  - Jul 2005 - Feb 2008
    Project Consultant / OptimiseIT
    
    Projects I worked on at ANZ Mortgages included;
    - Strategic planning
    - Major IT programs
    - Enhance corporate web site (sales channels)
    - Six Sigma projects
    - Training and coaching staff
  - Jul 2005 - Dec 2007
    Project Consultant / ANZ
    
    Working via OptimiseIT
  - Dec 2006 - Apr 2007
    Project Manager / Telstra Business
    
    Managing new products to launch for Testra's business customers.
  - Sept 2003 - Feb 2007
    Director / erina legal
    
    Erina Legal is a law firm based upon the Central Coast of NSW.
    
    The practice areas are Family Law, Property Law (especially conveyancing), Business Law, and Wills and Estates.
  - Dec 1997 - 2005
    Various roles / Optus
    
    Project Manager, Manager of the Business Process Improvement (BPR) Team, Business Analyst, IT Management, Technical support.
    
    For me, Optus was several years of working with great people on cool projects.
  Education
  - 2005 - 2007
    
    RMIT University
    
    Masters in Project Management
  - 1990 - 1994
    
    University of Newcastle
    
    Bachelor in Business
  - 1983 - 1988
    
    Henry Kendall High School
  Additional Information
  - Websites:
    
    Blog, Company Website, Personal Website

Craig Brown

No wonder our perception of project work is distorted.

No wonder we have negative images of our own working practices.

The Business Model of the PM Professional Bodies/Institutes: Frozen in time

The unseen consequences of failing projects: they don’t fall 30,000 feet, but there are casualties

Installing scrum - the hard way

An open letter to project managers

References