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
- 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.
- The People's Scrum by Tobias Mayer
  
  Sep 04, 13
  I think this book by Tobias is beautifully written. There is real craftmanship in the prose here.
  
  The book is made up of independent self contained stories and reflections on various themes related to the Agile Software Development movement. Each one is a parable seeking to impart some of Tobias' wisdom onto the reader.
  
  Hopefully people will be open to the ideas. It isn't for beginners or for people who think agility is about technical excellence alone. It is about values and mindsets and the way we choose to live.
  
  Some of the parables are better than others, and it is slightly uneven, but overall, it has a great message and is of great quality.
  
  You may well already know everything he wants to share, but hearing these stories and reignite spirit and passion, and if this ideas are new to you, then you'll be charged and energised at the opportunities waiting for you.
  
  Get the book here.
- Agile Project Management at Swinburne University
  
  Sep 04, 13
  
  Berndt Schiffer and I are delivering an Agile PM masterclass course on 28-29 October. We'd love to have you come along and spend the time with us.
  
  This two day Masterclass commences with an introduction to the foundation and history of the Agile movement. It then looks at common practices and frameworks used on Agile teams including Scrum, Kanban, Lean Start-up and XP.
  
  Day two drills into project management activities related to planning, monitoring and controlling projects highlighting the role of collaboration, developing appropriate feedback and quality systems, including elevating the focus from schedule and budget targets to delivering customer value.
  
  You can sign up here.
- An Agile Adoption and Transformation Survival Guide by Michael Sahota
  
  Sep 03, 13
  
  This afternoon I read Michael Sahota's book An Agile Adoption and Transformation Survival Guide: Working With Organizational Culture (which you can download from here.)
  
  It's short and I read through it in about an hour. In it Michael addresses the context teams at work operate in; organisational culture. The premise is that agile adoptions are a dead end unless you tap into the cultural context.
  
  There is an opening discussion that addresses the Do Agile v Be Agile paradigm, acknowledging the agile community discussions which have gone before, and then settling in with the fundamental premise of the book; most people want to do agile and don't want to be agile.
  
  Culture change is hard, and often those in power don't want to pay the cost. Often in fact, it isn't needed. And when your client only wants agile practices you get a whole range of options to play with that are useful, valuable, and worthy. But not as hard.
  
  Michael applies a model which looks at culture across two dimensions; people v company orientation and reality v possibility orientation. By understanding where you client is, you are better able to talk about where they want to go.
  
  Is your culture agile?
  Even better, you have Kanban and Software Craftmanship to address cultures that aren't ready to adopt an agile spirit.
  
  I am familiar with culture change programs, and with working in a team culture in conflict with organisational culture, and I don't think culture change is impossible. I do think it takes a concerted effort though, and you'll need to try a few things out before you really find the right path.
  
  Michael seems to come to the conclusion that usually it's a waste of time to try to shift culture, but practices that suit the dominant culture can be found, and applied in useful ways. I'm not sold on this, but I understand it, so to that end, I find this book a step on a communal journey rather than a final statement on culture change for agile teams and consultants.
  
  It is easy to read, the ideas are presented in simple and accessible ways, and it is a very worthy topic. If you are in the business of change at any scale I highly recommend you invest a few mouse clicks and some reading time.
- Lean & Agile Project Management Using Scrum
  
  Aug 31, 13
  
  Neil and I ran a training day yesterday with a diverse set of Melbourne people. It went well. We surveyed the team on the day and got a pretty favourable NPS score of 57 with lost of positive sentiment. It felt valuable and useful to me as well.
  
  Themes that came through strongly in the discussions include the importance of data, and in who is wielding power, and that it's not about the practices so much as the values. Naturally.
  
  We will run the course again. You can sign up if interested at Neil's website.
- There are three types of people in this world...
  
  Aug 30, 13
  Yes, we were in a bar, and no we were not particularly sober. Or at least I wasn't.
  So, I hesitate as I post Mark's meme. But only for a minute.
  
  Here is the idea;
  
  There are three types of people we manage at work.
  
  People who make shit up
  People who build shit
  People who measure shit
  
  What do you think?
- I am speaking about Collaboration at PMOZ (17 September)
  
  Aug 29, 13
  I am speaking at PMOZ, an Aussie project management conference on the 17th September. I have the plenary spot on day 1 of 2. It's the pre-cocktail session so that helps me understand the mindset and intentions of the participants :)
  
  I'll repeat the Collaboration workshop I did at the SharePoint conference earlier in the year.
  
  The difference this time is the venue and audience. I am not dealing with 50 Sharepoint techies and knowledge management types this time. It's grizzled "big engineering" and military project and program managers and it's the whole crowd.
  
  Now. How do I architect a 400 person group hug?
  
  Here is the accompanying deck.
- It starts with the customer
  
  Aug 26, 13
  
  Given the Jobs movie is on it's way... and what we are talking about these days (over and over again)...
  
  Making apps might be hard, but the rally hard bit is bringing it up to a cohesive whole that means something to customers.
  
  And plenty of other good little quotes as we..
- LAST reflections
  
  Aug 13, 13
  
  We ran the second LAST conference a few weeks ago and I finally have a few minutes to reflect and it appears I have a lesson for myself in there.
  The day was anchored in values and principles
  You might already know that LAST conference ran on 2nd August and we hosted 70 speakers (some in pairs) and about 370 total participants. It was a day that buzzed with energy. It is essentially managed by Ed and me, with on-campus assistance from Raj and Paul. It’s a lightweight team compared to many other events.
  
  That explains why we are so tired the weekend after the conference.
  
  But it also encourages us to be lean and innovative in the way we do things. I wanted to share some examples with you in the hope they inspire you to some new insight. The three key themes that I am thinking about are typical management issues in most businesses; Mission and purpose, Decision making and Collective Ownership.
  Stephanie BySouth leads a discussion on coaching
  
  Mission and purpose
  What was our purpose in running this event? It doesn't make us money. (In fact we lose money due to sacrificing work days to organise it.)
  
  We mainly did it because people wanted it to happen.
  
  There is some back of mind idea that one day it will be worth money, but we don’t have any plans to act on that desire. What we want to do is run a great event for the community that we are a part of here in Melbourne, and to some degree our neighbours in nearby states and NZ.
  
  We also like the energy of the day, and enjoy being a part of the vibe.
  
  It’s great being a part of this community. One of the reasons I was originally attracted to the agile community is it’s passion for exploring and learning. And that was at the heart of the day. Not everything that was presented was necessarily useful or even valid –but it is a part of a wider exploration into better ways to do business.
  
  My favourite part of the Agile Manifesto is “We are uncovering better ways of developing software by doing it and helping others do it.” This day definitely aligns to that agenda.
  
  So we don’t have a particularly strong lock on our mission, but it is loosely “run a cool event that you can be proud of.” And that doesn't steer us just at the content, but at the culture of the community, the things these people value and the style of interactions they value.
  
  We think we have a bead on this, but also think we are just beginners and hope to see this get better in the future.
  Lunch boxes (care of REA and Cafe Blac) encouraged people to go and talk to each other.
  Decision Making
  With just a handful of organisers we had to make decisions quickly and efficiently. In a conversation on the day I described our decision making protocol like this;
  
  “Someone makes a decision and then it’s made. If you don’t like a decision, make another one.”
  
  We didn't articulate it. We just identified it in retrospect. And on several occasions Ed or I made decisions that the other thought were bad, or could have at least been better. And sometimes Ed would make a decision that I thought was bad, but I ended up being proved wrong.
  
  I don’t think we ever over-rode anyone else’s decision. There wasn't time to second guess too much, and we certainly didn't want to waste our energy on low value discussions. Good enough – as intangible and contextual a thing as it is – became the default acceptance criteria.
  
  I think this was one of the most interesting aspects of the way we managed this event. There was no issue of power or authority to get in the way so we just got on with business.
  Martin and Abi talk about discipline in the Speaker's corner
  Collective Ownership
  An important aspect of the day for us is that it feels like a community coming together. So to that degree we want to community – or speakers, facilitators and participants, to come together and feel like they are doing something to make the day successful.
  
  Our solution to this was to do less. We didn't have people managing track is or rooms, we didn't have people helping the speakers. We enlisted the first people we knew that arrived in signing people in (via a handy Eventbrite app.)
  
  We didn't have breaks between sessions. Instead we asked speakers to interrupt their predecessors if they were going over time. That was everyone is accountable for the day.
  
  I think we want to amplify this aspect in the future.
  
  Overall we are thinking we did a pretty good job. Cheap, fast and good. And we did learn a few things we think we can improve on, and hope to get some more feedback via a survey we sent out to the attendees yesterday.
  
  These are my thoughts so far. I'll ask the others to chip in and comment. Also - If you were there on the day in any capacity – what did you think?
- Agile PM courses in Melbourne
  
  Aug 12, 13
  
  I need your help.
  
  I am involved in creating and delivering two courses for Agile Project Managers. I am hoping you can spread the word for me to help fill them with enthusiastic project managers.
  
  Please pass these links on to your network.
  
  Lean & Agile Project Management Using Scrum
  The first is a one day advanced practitioner workshop with both Craig brown and Neil Killick.
  This one day workshop style event is the place to go for project and product managers to go if you have extensive experience with Agile projects and are looking to raise their performance even further.
  This one day course runs on 30th August and is available from $499 and you can book at Eventbrite.
  
  Agile Project Management master-class
  The second, with potentially more widespread appeal is a course run by me in partnership with Swinburne University. It rolls into a Graduate Certificate in Business at the uni, and runs for 2 days. This course covers agile practices in general and then drills into planning and monitoring a project using agile practices and methods.
  
  This 2 day course runs on 28 October and costs $1400. You can sign up at Swinburne's website.
  
  Thanks in advance for passing this around.
  
  Craig
- The feedback sandwich method – would you use it?
  
  Aug 09, 13
  
  Today a guest blog from Alison Wood, the Communications Manager and graphic designer for Knowledge Train, a London based project management training provider.
  When working in any kind of management position, giving constructive criticism to your team is vital for the growth and success of the business, and to develop the team’s skills. As a project manager it is your responsibility to deliver products on time, which also means motivating and supporting your team in meeting those goals. Unless you had an absolutely golden team who were perfect from the word go, I’m not sure how goals would be met without constructive feedback along the way.
  
  One way of giving constructive criticism is using the sandwich method, as seen in the infographic. It is a widely known technique that helps the manager remain sensitive to the employee’s feelings, and keep the atmosphere positive and motivating. Constructive criticism that is tactfully given is something of great importance to me, and I’ve eaten quite a few feedback sandwiches in my time. Although I think this is a tasty way of giving feedback, I was left with a different taste in my mouth when I introduced the topic to the online project management community. Please see below, to see what you make of this unsavoury reaction.
  
  “Once you use the feedback sandwich method, every time you praise your employee they will be waiting for the slap in the face.”
  
  Most humans are clever creatures and shouldn’t feel deceived by being given a feedback sandwich. If the manager is giving a feedback sandwich several times a day, then maybe they would become attuned to it. If the constructive and positive feedback is given in proportionate amounts, (and if the manager isn’t lying for the sake of something positive to say), then the employees should appreciate both sides of feedback and be raring to go the next day.
  
  “A manager can’t play “Good Cop/Bad Cop.”
  
  I don’t think there is any need for the manager to be acting in this way. If they are supporting the employee during the entire meeting on how to improve on the behaviour in question, then the atmosphere and tone should remain neutral throughout.
  
  “The rule of thumb when giving feedback is to separate the behaviour from the person, to avoid any accusation. With this in mind, why would you need to “sandwich” the criticism between praise?”
  
  I agree that separating the behaviour from the person is a must when giving feedback, to avoid the employee feeling personally criticised. This comment is highlighting a very good point, presuming that the employee reacts in the desired manner.
  
  “The sandwich is simply a dishonest approach to giving feedback.”
  
  A good manager should not lie to their employee about their strengths just for the sake of cushioning some constructive criticism. Every employee has strengths that make them good for the role, but not every employee recognises them. The feedback sandwich method addresses this and gives an all round perspective of the employee’s work.
  
  “The impact of the criticism is going to be diminished if you squash it with praise. The employee is likely to forget about it by the end of the meeting.”
  
  The negativity bias theorysuggests that humans have selective attention towards negativity, placing more weight to negative information rather than positive. Taking this theory into account – I don’t think it’s likely that the employee is going to ignore the constructive criticism. I think the sandwich method uses the positive comments to support the criticism, to remind the employee of their strengths and how they are going to improve their behaviour. Without the supportive positive comments, there is a chance the employee could become defensive.
  
  The feedback sandwich method is still a personal favourite of mine, obviously depending on the employee and the situation in question. Employees work harder when they feel supported by their manager. Now you have heard two sides of the story – what are your thoughts and experiences with the feedback sandwich?
Tweets

Tweets

Profile
- What is it like when it's magical http://t.co/jaaex9xnli #pmot #baot
  
  Dec 05, 13 from twitterfeed Reply, Retweet, Favorite
- I before E except after C. Weird?
  
  Dec 04, 13 from Twitter for Android Reply, Retweet, Favorite
- RT @ShaunCoffey: Australia’s Eureka Flag Finds a New Patch http://t.co/7iruOjEii2
  
  Dec 04, 13 from Twitter for Android Reply, Retweet, Favorite
- The Business Model of the PM Professional Bodies/Institutes is frozen in the 1980's. Read why here. http://t.co/SWNQSi0Noo
  
  Dec 04, 13 from TweetDeck Reply, Retweet, Favorite
- This is amusing; last summer we did a meetup in a laneway. 6 thinking hats applied to scrum http://t.co/gWpm31djBq
  
  Dec 04, 13 from TweetDeck Reply, Retweet, Favorite
- How corrupt is your country? http://t.co/Z7kpt9hMXJ
  
  Dec 04, 13 from TweetDeck Reply, Retweet, Favorite
- @MarkAtScale which type? So many options
  
  Dec 04, 13 from Twitter for Android in reply to MarkAtScale Reply, Retweet, Favorite
- @dwwright99 thanks for the suggestions
  
  Dec 04, 13 from Twitter for Android in reply to dwwright99 Reply, Retweet, Favorite
- @dwwright99 owner/customers
  
  Dec 03, 13 from Twitter for Android in reply to dwwright99 Reply, Retweet, Favorite
- RT @LeanVoices: Matrix management structures happen when management run out of ideas.
  
  Dec 03, 13 from Twitter for Android Reply, Retweet, Favorite
- I need your assistance: What are some good ways to visualise product architecture?
  
  Dec 03, 13 from Twitter for Android Reply, Retweet, Favorite
- Who has been watching Black Mirror recently?
  
  Dec 03, 13 from Twitter for Android Reply, Retweet, Favorite
- @wileyfuller oops http://t.co/EcJXGKigKp
  
  Nov 30, 13 from TweetDeck in reply to wileyfuller Reply, Retweet, Favorite
- @wileyfuller I will thanks. Also see this 3 month summary of the government so far. Stunning, despite some obvious rantiness
  
  Nov 30, 13 from Twitter for Android in reply to wileyfuller Reply, Retweet, Favorite
- Australian politics is fascinating these days... Like driving past a train wreck piled on top of a truck crash
  
  Nov 30, 13 from Twitter for Android Reply, Retweet, Favorite
- Rob Thompsett quoting Darth Vader at 10 Stories http://t.co/KMqz54qQjh
  
  Nov 28, 13 from Twitter for Android Reply, Retweet, Favorite
- @mcbridesride but that night was pretty epic
  
  Nov 28, 13 from Twitter for Android in reply to mcbridesride Reply, Retweet, Favorite
- @mcbridesride fair enough
  
  Nov 28, 13 from Twitter for Android in reply to mcbridesride Reply, Retweet, Favorite
- Good hair helps http://t.co/17D7vvgTgL
  
  Nov 28, 13 from Twitter for Android Reply, Retweet, Favorite
- We are replacing code reviews with a new challenge. Come work at @aconex http://t.co/wssAf3DRc5
  
  Nov 28, 13 from Twitter for Android 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
- Dispatches
  
  Nov 28, 13
  
  Melbourne Agile and Scrum User Group
  
  We have had members of this group head overseas and participate in a number of Agile events. Tonight we put them together on a panel ans share their experiences and insights.
  
  The agenda: What is happening around the globe, what's new in the agile world?
  
  On the panel:
  
  • Neil Killick, via Agile Scandinavia and Agile Singapore
  
  • John Sullivan, via Agile Malaysia
  
  • Ed Wong, Agile Singapore
  
  • Anton Rossouw, A week with Nassim Taleb in Chicago
  
  • mark Richards, Several USA events
  
  More tbc
  
  *If you want to be on the panel let me know.
  
  Melbourne - Australia
  
  Wednesday, December 18 at 7:00 PM
  
  Attending: 25
  
  Details: http://www.meetup.com/scrum-12/events/152577242/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, January 29 at 6:00 PM
  
  Attending: 6
  
  Details: http://www.meetup.com/scrum-12/events/124236752/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, February 26 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/scrum-12/events/127358712/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, March 26 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/scrum-12/events/142133502/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, April 30 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/scrum-12/events/147672012/
- Scrum Monthly Meet-up
  
  Feb 19, 13
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, May 28 at 6:00 PM
  
  Attending: 2
  
  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, July 30 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/scrum-12/events/148222312/
Posts

Posts

Feed
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, December 10 at 6:00 PM
  
  Attending: 27
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/121289472/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, January 14 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/129995082/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, February 11 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/124236792/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, March 11 at 6:00 PM
  
  Attending: 4
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/127358752/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, April 8 at 6:00 PM
  
  Attending: 3
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/146845272/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, May 13 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/146845242/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, June 10 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/147672412/
- Monthly Agile BA meet-up (schedule a topic!)
  
  Jul 07, 11
  
  Agile Business Analysts, Melbourne
  
  Melbourne - Australia
  
  Tuesday, July 8 at 6:00 PM
  
  Attending: 2
  
  Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/148222242/
Info

Info

Profile
- Craig Brown
  
  Senior Engineering Manager 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

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