I've been having an unlucky streak with my reading recently (see here and here). So, I am pleased to say that the latest read, "Communicating Strategy", by Phil Jones, was pretty good, though not great.
As with my previous reviews, I am bound to state upfront that I had high expectations of this book. I really enjoyed parts of it; Phil Jones clearly has a huge amount of experience as a coach and performance consultant and the book contains many interesting examples of how to approach strategy development and communication. The style is easy and I liked the fact that he did not provide a simple checklist reminding us to think about the audience, build a compelling story, consider the mode of communication etc. (see here for a posting on my aversion to checklists!), but rather opted for a more rhetorical approach (putting out questions without direct answers at the end of each section to make you think).
I particularly liked the second chapter, which describes "Ten Heresies" in his own thinking towards communicating strategy. That "people are not stupid", that you can "trust people" and that "you can over communicate" are certainly positions that I entirely agree with.
But what I liked most about the book was the constant reminders it contained to think consciously about what and how you communicate to whom.
It is easy to get into a rut in communications - everyone has a style they are most comfortable with and tend to use it irrespective of audience and need (I personally find it very helpful simply to try different communications techniques/modes just to force myself to think consciously about what it is I want to communicate from as many different stakeholders' perspectives - even if you end up shifting back to your comfort zone - as I personally undoubtedly often do - the act of considering things from multiple angles typically gives you insights that improve your thinking).
This is a good book with a lot of simple advice. Beware though that it also contains considerable references to NLP techniques - certainly interesting but not everyone's cup of tea.
Thursday 17 June 2010
Tuesday 8 June 2010
Systems thinking - book review
Another short post. As mentioned earlier this year, I am merrily working my way through the enormous backlog of books that I built up over the Christmas holidays.
The latest book was "Systems thinking - managing chaos and complexity: a platform for designing business architecture". Just from the name, I had high expectations. Add to this the author, Jamshid Gharajedaghi, a protege of Russell Ackoff (Mr Systems Thinking) and I was really looking forward to this book.
I was disappointed. Now, the difficult thing is that I am not sure whether to be disappointed with the book, or myself; I did not understand half of the thinking in the book. Every time I thought I had a grip on a concept and how it related to the other parts of the frameworks presented, Gharajedaghi applied it in a way that I could not follow.
I am intuitively drawn to systems thinking (with its emphasis on the whole, on the interdependence of working parts in a system, organisation or problem and the analysis of their relationships with one another) and am sure that this book does provide lots of good material for those that have truly understood the basics, but as a primer, I have been defeated.
Next on the list: "Thinking in systems" - perhaps I will have more luck with this one - post to follow later this year.
The latest book was "Systems thinking - managing chaos and complexity: a platform for designing business architecture". Just from the name, I had high expectations. Add to this the author, Jamshid Gharajedaghi, a protege of Russell Ackoff (Mr Systems Thinking) and I was really looking forward to this book.
I was disappointed. Now, the difficult thing is that I am not sure whether to be disappointed with the book, or myself; I did not understand half of the thinking in the book. Every time I thought I had a grip on a concept and how it related to the other parts of the frameworks presented, Gharajedaghi applied it in a way that I could not follow.
I am intuitively drawn to systems thinking (with its emphasis on the whole, on the interdependence of working parts in a system, organisation or problem and the analysis of their relationships with one another) and am sure that this book does provide lots of good material for those that have truly understood the basics, but as a primer, I have been defeated.
Next on the list: "Thinking in systems" - perhaps I will have more luck with this one - post to follow later this year.
Monday 7 June 2010
Scrum, agile and "real' project management methodologies
I have been following a blog "Better projects" for a while. A recent post arguing that "scrum" (an agile software development methodology) can represent a complete answer to project management for certain projects, reminded me that I had been intending to post a couple of thoughts on this matter myself:
In my humble opinion, agile project management (as a philosophy, rather than the specific flavour of agile suggested by Jim Highsmith - see also here for more on that), informs all areas of project management and the application of the principles found in and around the agile manifesto, can certainly provide answers and guidance to most/all parts of a project.
This does not, however, necessarily mean that scrum can entirely replace "real" project management methodologies.
In the context of full disclosure, I feel I should out myself at this point as a fan of agile approaches in general and - on the whole - of scrum as a specific flavour of agile (though, as with any methodology it has advantages, disadvantages and should be applied carefully, taking into consideration the context of the actual project...).
A few years ago, I did a bit of thinking about how the various agile frameworks map to the various project management disciplines and how they can effect the degree of risk on a project as part of a Masters degree that I did in my spare time. Back then I came (amongst other things) to the following conclusions:
It should be noted, that this thinking was done in an academic context and consequently involved a good deal of defining and differentiating terms (eg. agile "philosophy", "method", "methodology", "approach", "framework"), but I still absolutely stand by the findings (and they have been stated in the meantime several times over by many people much smarter than I (see also here for more details from someone who really understands this stuff in detail!): any framework is just that, a framwork - it does not replace thinking and applying one's knowledge to a given environment and project to adapt and use a framework.
I have nevertheless attached a few of the overview diagrams from the introductory/definitions section of the paper below for those that might be interested:
1. "Framework" for the analysis that combined "pure" project management and software development frameworks (since I argued that many of the agile project management approaches stretch across areas of both such frameworks):
2. An overview of how scrum and xp map to this framework
3. The resulting mapping of these methodologies to the idealised framework (where a "full-score" would be attained if all areas were fully addressed - unrealistic for any framework).
If you are interested in more detail and the other findings (based upon survey and case-study, and more explicitly describing the ways in which different types of risk are addressed using agile methods), please contact me directly, since the material cannot be shared in its entirety without permission from the university, myself and the participating companies.
In my humble opinion, agile project management (as a philosophy, rather than the specific flavour of agile suggested by Jim Highsmith - see also here for more on that), informs all areas of project management and the application of the principles found in and around the agile manifesto, can certainly provide answers and guidance to most/all parts of a project.
This does not, however, necessarily mean that scrum can entirely replace "real" project management methodologies.
In the context of full disclosure, I feel I should out myself at this point as a fan of agile approaches in general and - on the whole - of scrum as a specific flavour of agile (though, as with any methodology it has advantages, disadvantages and should be applied carefully, taking into consideration the context of the actual project...).
A few years ago, I did a bit of thinking about how the various agile frameworks map to the various project management disciplines and how they can effect the degree of risk on a project as part of a Masters degree that I did in my spare time. Back then I came (amongst other things) to the following conclusions:
- There is little that is contradictory between more traditional project management "meta"-frameworks like the PMBOK from PMI and agile methods though they do not bear direct comparison in all areas and in some areas they extend into software development (ie. domain specific disciplines) not covered explicitly by project management frameworks.
- Conversely, PM frameworks do address explicitly areas that are only implied or hinted to in agile.
- As such scrum can usefully be augmented by other practices (particular in the area of HR, but also in procurement, risk management, cost management etc.).
- Usage of scrum (and other agile methods) can lead to a reduction in risks on projects
- ...But this depends entirely upon the way it is applied.
It should be noted, that this thinking was done in an academic context and consequently involved a good deal of defining and differentiating terms (eg. agile "philosophy", "method", "methodology", "approach", "framework"), but I still absolutely stand by the findings (and they have been stated in the meantime several times over by many people much smarter than I (see also here for more details from someone who really understands this stuff in detail!): any framework is just that, a framwork - it does not replace thinking and applying one's knowledge to a given environment and project to adapt and use a framework.
I have nevertheless attached a few of the overview diagrams from the introductory/definitions section of the paper below for those that might be interested:
1. "Framework" for the analysis that combined "pure" project management and software development frameworks (since I argued that many of the agile project management approaches stretch across areas of both such frameworks):
2. An overview of how scrum and xp map to this framework
3. The resulting mapping of these methodologies to the idealised framework (where a "full-score" would be attained if all areas were fully addressed - unrealistic for any framework).
If you are interested in more detail and the other findings (based upon survey and case-study, and more explicitly describing the ways in which different types of risk are addressed using agile methods), please contact me directly, since the material cannot be shared in its entirety without permission from the university, myself and the participating companies.
Subscribe to:
Posts (Atom)