I haven’t been here for awhile and while I’ve been busy (actually, very busy) I couldn’t resist the following message:
WISHFUL THINKING IS NOT A RECOMMENDED RISK MITIGATION STRATEGY
Think about it!
I had the pleasure of presenting at the Australia PMI Conference in Melbourne yesterday. The topic was “Transform yourself from Traditional to Agile Project Manager”.
In case you’re in Melbourne early September and happen to attend the Australian PMI Conference don’t forget to look me up. I will be presenting a session on “Transform yourself from traditional to Agile project manager”.
Here’s my submitted abstract:
For many ‘traditional’ project managers the encounter with agile and agility is a confrontational one. While many project managers have been trained in the art of project management based on a set of governance principles grounded in command-and-control related management techniques; managing projects in the 21st Century is developing in an environment in which agility, collaboration, exploration and adaptation are the key. This session will highlight the key issues facing project managers wishing to engage in this transition, explore the key dimensions – behavioural, conceptual and psychological – associated with this transformational change and provide a road map and a range of helpful tips for a successful incorporation of agile principles into any mode of project management, irrespective of the environment in which it will be executed.
I am hoping that by the end of the session the participants will:
1. Understand the conceptual differences between traditional project management methodologies and agile management principles
2. Be equipped with a set of tips for the incorporation of Lean and Agile principles, values and techniques in your project management activities – irrespective of the type of project management methodology you use for your projects.
3. Have a better understanding of Agile project management terminology.
Let me know if you’re going to attend and please come and introduce yourself.
I come across ‘coaches’ that certainly ‘talk the talk’ but have no real experience to back that up.
And here’s my dilemma:
Should I take such coaches seriously?
Can one become a coach by knowing the domain (as opposed to ‘doing’ in the domain)?
Am I just too damn closed minded?
Think about it!
Think about it!
If there is anything we can and have learned from the Global Financial Crisis is that what we were taught at university in the 80s was blatantly wrong. The over reliance on mathematically elegant Macro Economic models at the expense of the necessary immersion in what makes the REAL world work. I can recall with some sense of apprehension the aesthetically beautiful graphical models showing how market forces will emerge to push markets into an efficient equilibrium. No one considered, let alone elaborated, on the impact of behavior, attitudes and – most importantly – the very lessons we can learn from observing and interpreting past events.
Reflecting on our very own domain – project management – we can, and indeed should – ponder the possibility that perhaps the way we train and educate aspiring project managers is partially or totally flawed.
Unlike some other professions (and ignoring for a moment the potential discussion around whether or not project management is a profession), one can become a project manager having taken a number of alternative paths. I, for instance, have started my professional life as an economist, have then become a software programmer, a systems analyst, a business analyst and then a project manager. My project management knowledge and experience evolved through observation, on-the-job and formal training and, at some point in time, through the codification of that journey using the PMBOK / PMP accreditation process.
What troubles me in the path I have taken is the fact that it is superficially tilted towards the application of processes and the reliance on ‘best practices’. The PMBOK, for instance, is rampant with linear processes coupled with supporting tools and techniques. It does not force you to use them all or follow them dogmatically but it certainly suggests that in the application or execution of an average project many of these processes, tools and techniques would be a useful thing to consider.
And here’s what is wrong with this approach:
It lacks explicit and direct attention to the body of evidence and case studies researching the reasons for failed projects. It makes no explicit attempt (except for the superficial incorporation of ‘Organizational Process Assets’) to formalise a body of knowledge for practitioners to explore, evaluate and learn from other people’s successes and failures. It totally lacks any retrospection and constant self-evaluation.
Furthermore it lacks context or any appreciation of situational circumstances. Think Cynefin, for example, and you will immediately see that the execution of projects in any one of the four Cynefin quadrants would be completely different and require different skills, different approaches and different tools and techniques. If you approach project management as a linear process you will fail before you even started your journey.
So the next questions we need to look at are:
What steps do professional organizations (like the PMI, and others) take to make sure that certification is indeed relevant and takes into account the proper parameters necessary to be an effective and well-informed project manager (incorporating such knowledge areas as ethics, history of project management, behavioral economics, etc)?
What role do universities and other educational institutions play in ensuring the correct knowledge is taught?
Only a collaborative approach between education providers and accreditation institutions can close this gap.Universities and other institutions need to make sure that project management is being taught not as an engineering course but as the new economics ought to be taught, taking into account the various disciplines necessary to produce a ‘ready to go’ project manager. Accreditation organizations need to reciprocate and adapt by insisting on having these parameters reflected in their accreditation curriculum.
Not implementing the above approach will not be disastrous it will just mean that as a collective we will continue to be mediocre.
Think about it!
Couple of months ago I was approached by Geoff Crane, a blogger and a Professor of project management at Durham College, to assist with the following request:
I teach project management at Durham College in Ontario. My first batch of students will graduate next month and as a gift I’m looking at putting together an eBook for them…
What advice do you have for project management students fresh out of school who want to break into the discipline?
This is a burning issue for most of them–they’re really looking for advice. As someone with a vested interest in the field, I know your insights will be valuable.
The fruit of my (and other 51 contributors) labor has been collated into a fantastic eBook titled 52 Tips to Break Into Project Management (see also on Slideshare). You can also read my own response below:
Project managers are usually seen by society, and unfortunately by themselves, as being the delivery arm of the organization. As such, one might conclude, their role is not dissimilar to that played by the hand in the human body. The head is where the scope and the vision are being formulated and these sets of governing concepts and rules are then being transmitted to the hand to carry them out. The hand, in this crude analogy, has no room – nor any capacity – to play a devil’s advocate and challenge the brain for the validity of its decisions and as such is expected to blindly follow the instructions received and carry out prescribed mission.
Being a project manager requires one to deliver, to meet objectives, to produce the results, to follow the path chartered for it by its stakeholders. An aspiring project manager might think, not unexpectedly, that he or she has no role to play in validating the morality – in the widest possible sense of this term – of the actions it is asked to lead. Regardless of the domain in which you will find yourself, you will always come across (provided you keep your eyes opened to such situations) where you will need to validate your actions against your moral compass. These might be internal to your project – like, for example, the way you tread your team, the way you respond to pressure and the way and methods you use to communicate with peers and subordinates – or external – where you might turn a blind eye to the impact of the project you are managing on the environment, on people and on society as a whole.
Having been in this game for some time now I lament the fact that in my earlier days no one introduced me to the need to evaluate my actions, all my actions, against my value system. Had I been alerted to this possibility I might have, and quite likely would have reacted differently to some earlier circumstances where I was not yet fully aware of my options and assumed, incorrectly, that my job is to deliver – no matter what.
Think about it!
The Cynefin framework identifies five domains within which systems and environments can co-exist. In summary the five domains are:
When tying the concept of software development estimation with the Cynefin framework one has to consider (or rather ‘sense’) in which domain the system and the environment are and, based on that assessment, tailor the estimation process to account to that situation. The situations most likely to be present at the outset of the estimation process are as follows: Some of the objections to carrying out estimates touch on the variability (or rather uncertainty) associated with the state of either the System or the Environment. The Cynefin Framework recognizes the difficulty associated with managing complex situations and suggests an approach to effectively get them managed. Tackling complexity requires resident knowledge about the system and its environment and, more importantly, requires adaptation and openness to learn about them. Experimentation management is the key to overcome the fear of tackling the unknown. Rather than adopting an attitude of ‘it cannot be done’ I would suggest that an attitude of ‘let’s put in a place a process of experimentation so we can tackle the unknown’ would better serve the needs of both those delivering the estimates and those requiring them for business decision-making. Think about it! aaa
Greetings from Melbourne, Australia.
I can’t prove it but I believe that the way we execute the precepts of project management is, at least to some degree, determined and influenced by our cultural surroundings.
Melbourne is, by all accounts, a fantastic cosmopolitan city. It is a place where people of diverse and different backgrounds, cultures and nationalities have come together and call this place ‘home’.
While the ‘hard’ aspects of project management (in which I mean to include the core techniques used by most project management methodologies) are fairly universally implemented, it is in the ‘soft’ aspects that people of differing backgrounds will differ from one another.
Using a bit of an extrapolation from my experience in the Southern Hemisphere (both in New Zealand and Australia) I would be happy to suggest that the management style exhibited in these countries is by far different than the one illustrated in American based movies and TV series. This is equally manifested in the area of project management where the need to deliver is complemented by a ‘fair go’ approach.
On a different front, just like the rest of the world, Australia is always quick to adopt current and innovative management ideas. In recent years the ‘migration’ to agile and agility is taking hold in many organizations. And just like other countries, Australia too is undergoing a transition from a bottom-up to a top-down drive for implementing agility across the organization. This, however, is not a seamless or easy journey and many companies are in the process of finding their own way and inventing their own path in that transformation effort.
While I live and work in Melbourne, I have access to the vast knowledge base, experience and stories produced on a regular basis around the world. The ability to listen, read and collaborate with people from all over the world makes the geographical separation that much less important. The use of social media tools enables me to connect with other like minded individuals at any time and in any place and I can’t wait to see what other technologies will come our way in years to come to make such interactions and collaborations even easier.
About “#PMFlashBlog – Project Management Around the World”: This post is part of the second round of the #PMFlashBlog where over 50 project management bloggers will release a post about their view of project management in their part of the world.
Despite our best endeavors in codifying many aspects of project management, a lot of what we do in project management is still ‘situational’ and ‘variable’. That is, in project management we need to react to various situations and these situations are a result of any number of variables, the impact of which cannot be fully predictable, understood or comprehended in advance (and occasionally not even while or after they occur).
In this post I want to elaborate on the applicability of a common framework that project managers can use in order to map various situations in their project landscapes. The framework I would use for this discussion is called Cynefin (pronounced cenevin).
Cynefin, the details of which will be elaborated on below, provides a conceptual framework for making sense of the different landscapes faced within and by projects. In ‘faced within and by projects’ I mean to say that this framework can be used by the project manager to understand the various landscapes faced by the project (for example the stakeholders’ landscape, vs the development team landscape – and don’t worry if you can’t understand it now, all will be clear by the time you complete reading this post) or the landscape of the entire project, compared with other projects (for example, a web development project vs an R&D project).
The Cynefin framework recognizes that the situations and challenges we face can belong to one of four domains:
The ‘Simple’ domain is characterized by the following attributes:
In the context of project management, projects that operate in this space would be ones where the domain of execution is known, regular, predictable and with very low risk. For example, a software house specializing in the delivery of basic small business web-sites, where these web-sites are subject to a regular delivery routine and are subject to similar terms and conditions.
The way to deal with ‘simple’ problems (i.e. the way to make decisions) is by applying the sequence of sense-categorize-respond. That is, you start by assessing (or analyzing) the facts of the situation, followed by categorizing them (i.e. determining what best practice is relevant to deal with the situation) and then implement and execute this practice.
The ‘Complicated’ (‘knowable’) domain is characterized by the following attributes:
In the context of project management, projects that operate in this space would be ones where the domain of execution can be determined by utilizing existing expertise and the project’s risk can be assessed and managed. Less than trivial software development projects (i.e. projects where the level of uncertainty is not insurmountable) would fall into this space.
The way to make decisions in the ‘complicated’ domain is by applying the sequence of sense-analyse-respond. That is, you determine what possible practices would be appropriate for dealing with the situation and then, having selected one (based, perhaps, on the availability of experts in that particular domain) you then implement and execute this practice.
The ‘Complex’ (‘unknowable’) domain is characterized by the following attributes:
In the context of project management, projects that operate in this space would be ones with high level of uncertainty but where low-cost-of-failure experiments can be used to narrow down the uncertainty and suggest an acceptable path forward. The type of projects that fall into this space will be innovation or R&D projects.
The way to make decisions in the ‘complex’ domain is by applying the sequence of probe-sense-respond. That is, you start by probing (i.e. trialing out various options using experimentation), then identifying the methods that succeeded and can be used as future patterns of operations for the future.
The ‘Chaotic’ (‘unknowable’) domain is characterized by the following attributes:
In the context of project management, project that operate in this space would be ones with high levels of uncertainty through and through. This could include projects with lack of agreement on the project’s scope, business value, mode of execution in a technologically shifting environment.
The way to make decisions in the ‘chaotic’ domain is by applying the sequence of act-sense-respond. The first thing that needs to be done is to take some action (which may or may not work) in an attempt to stabilize the environment and reduce the chaotic nature of the project. One example for a possible action would be to simply stop the project but other options are certainly possible.
There is much more to the Cynefin framework than described above and you are encouraged to explore it further here.
Determining your position in the project’s organizational landscape is important not only because it can prompt you to take the appropriate corrective-actions but also because it could prevent you from applying the wrong solutions.
In the context of recent #NoEstimates discussions it seems to me that the application (or rather the suitability) of the #NoEstmates argument is really only applicable to the ‘Unknowable’ domains. There is no valid reason to suggest that within the ‘Known’ and ‘Knowable’ domains estimates could not be provided (as a matter of fact in the ‘Simple’ domain and with some expert advice in the ‘Complicated’ domain).
Think about it!