Project Leadership
Principle-Based Project Leadership (Published in Beta)
Overview
Project management has alienated so many of its “consumers” that it is hard to practice anymore. So many people just don’t want Project Management is selling, and with good reason.
The main reason project management is having difficulties is that their customers are no longer buying what project managers have to offer. The practice of Project Management needs to be made more relevant to its primary consumers: project sponsors, teams of people who are engaged to deliver the project, and who are going to be impacted by the project, both during and after.
The project context has changed dramatically over the past 20 years, but project management approaches have only tweaked themselves to address these changes such as newer approaches such as Agile.. Project management has lost its traditional footing, and has not been effectively replaced.
And yet some form of management is needed now more than ever: we have left a void in rejecting traditional plan-based approaches and replacing them with Agile approaches that are not designed for this purpose.
This book attempts to side-step the methodological debate by identifying the essence of project management (at least for software projects) so that it can be practised effectively but without method conflict.
Where Can I Find It?
I’ve decided to publish this book progressively on leanpub.com. In this way I can release early on the material that is already in existence, and thereby benefit projects and teams that are in need of this information. I can assess the level of interest for a book of this kind, and get immediate and useful feedback on the material as it is published. I can also pivot the book if necessary.
Please visit Principle-Based Project Leadership
The Art and Science of the Deliverable (In Development)
Overview
The concept of ‘Deliverables Management’ has been present during much of my Project Management life but it took a long while before my understanding went beyond the superficial. Deliverables Management is one of these ‘self-evident’ concepts that ostensibly requires no further explanation or expansion. The term ‘deliverables’ always seemed to have an obvious stand-alone meaning and was never properly described with process or usage, and therefore never properly leveraged as an effective tool in Project Management.
In Project Management’s ‘conventional wisdom’ it appears that the idea of a deliverable and its management is so obvious that nothing else is required.
This seemed to be a waste: there had to be more than a self-defining term that ‘everyone’ understood but few could explain. And so began my process of research and cogitation to find a better use for this term and to codify it as a useful model for software project development. I researched existing publications, I mostly found redundant, self-referential definitions and equally self-referential articles and little else – a “deliverable” is something that “gets delivered”; how it gets delivered is the subject of other techniques and processes. Fortunately there was the odd academic paper and some magazine and blog articles that helped frame some detail.
I’ve now been using Deliverables Management as an enabler to my own project management activities for over 10 years, progressively codified its usage and refined the benefits.
I have now been able to comprehensively put that knowledge into a coherent manner that can be shared.
With this book my intention is to provide both a definitional and practical elaboration on the concept of a deliverable, how to think about both its static and dynamic properties and how to improve just about any methodology or development process.
Where Can I Find It?
I’ve decided to publish this book progressively on leanpub.com. in this way I can release early on the material that is already in existence, and thereby benefit projects and teams that are in need of this information. I can assess the level of interest for a book of this kind, and get immediate and useful feedback on the material as it is published. I can also pivot the book if necessary.
Please visit The Art and Science of the Deliverable on Leanpub
On Being Self-Organized (In Development)
Overview
Self-Organizing Teams have developed a lot of airtime in recent years, having been mentioned explicitly in the Agile Manifesto. The problem is that there is little in the way of guidance on how these teams work and how they need to be enabled, nurtured and protected. There is no “manual for Self-organizing teams” that explains how it works. So team leaders and managers in many organizations decide to just jump in without guidance and try to figure it out by themselves. I mean, how hard can it be.
The truth is that creating a great team is hard enough as any manager should already know. But the concept of self-organizing teams doesn’t make this process any easier. Trying to enable or participate in a “self-organizing” team can be difficult and extremely subtle in what works and what doesn’t. It can be personally confronting on many levels, and requires a level of tolerance, agility, commitment and discipline that is far away higher than most ordinary teams.
I would have thought that it was both fundamental and obvious that you cannot manage a “self-organizing team” into existence. You can create the environment and structure, but then it is by definition up to the team members to manage themselves, with suitable guidance and support from the organization.
But often the first thing that happens is a team’s manager call a meeting and announce “congratulations, you guys are now a self-organizing team!”. The second sentence can be one of:
1) “Now, here’s what I want you to do”
2) “Now, off you go and self-organize yourselves for the next sprint”
Or similar statement.
Either of these two sentences from a manager can be dis-enabling. The first immediately undermines the announcement of the first sentence, by continuing directive behavior. The second sentence (unless closely followed by subtle influence and support) basically puts the onus back on the team, but without letting them know anything about what just happened. The obvious questions arise but are unanswered:
• “what are our boundaries?”
• “What can and can’t we decide as a team?”
• “Who do we turn to for problems?”
• “What resources are available to help us make this transition?”
That self-organizing teams fail to start or gel is unsurprising. And this just creates an excuse for managers to step in and say “this isn’t working” and go back to past practice.
This book aims to provide guidance in how this works, for both managers and leaders who must still participate in this process, as well as the participants, the team members and the managers who are all now part of this team structure. There are answers to the obvious questions, or at least ways of defining and agreeing on the answers.
Where Can I Find It?
I’ve decided to publish this book progressively on leanpub.com. In this way I can release early on the material that is already in existence, and thereby benefit projects and teams that are in need of this information. I can assess the level of interest for a book of this kind, and get immediate and useful feedback on the material as it is published. I can also pivot the book if necessary.
Please visit On Being Self-Organized
Social Trends
The UberMeister Chronicles (In Development)
(The Uber Experience)
Overview
Where Can I Find It?
I’ve decided to publish this book progressively on leanpub.com. In this way I can release early on the material that is already in existence, and thereby benefit projects and teams that are in need of this information. I can assess the level of interest for a book of this kind, and get immediate and useful feedback on the material as it is published. I can also pivot the book if necessary.
Please visit The Ubermeister Chronicles
Recent Comments