Wednesday, September 24, 2008
Thursday, February 15, 2007
Sunday, January 28, 2007
Example delivery roadmap summary visual
Monday, August 21, 2006
I particularly like the host's usage of the word 'architecture' in a sense which matches my own usage (where I define architecture as 'deliniated shared understanding' and management as 'what collaborating individuals share').
The host also makes some interesting asides about a more structural view of 'service-oriented architecture' (as opposed to the IT view of S.O.A.); an area that I'm currently also drafting some notes / diagrams for.
Unfortunately, the guest uses the word 'seamless' which you all know I hate with a passion. :-)
Tuesday, March 21, 2006
First draft of new article
How workflow management at all levels can keep things moving even when the 'big picture' hasn't been fully thought through, is unseen, or is unknowable; and how market-making collaboration technologies might be able to 'seamlessly' add insight while you work.
I've been thinking a little about the relationship between different types of workflow management. Within the broad category of workflow management I include personal workflow management, managerial workflow management, and organisational workflow management. I've always had a bit of a problem with the idea of workflow management, but in the last couple of years I have developed an appreciation of the skills and practices of workflow management in each of these forms. So I thought it was time I expressed some positive views about an area of management science, for a change. Though I'd still like to draw attention to the risks of potential excesses in their application. Particularly, as these were the basis of my original concerns with the technique.
Workflow management, as a set of practices and either individual or organisation behaviors, is another example of management as a technology. One of the core concepts the ManageWithoutThem model is to recognise that management itself can be viewed as a technology. Like any other technology, management has a number of characteristics: it can be measured by its degree of usability, it must be learnt and used by all participants in order to add value, it may benefit from network effects, and it can be improved or made obsolete by other technologies. Workflow management is an evolving paradigm of organising and collaborating technologies that provides a pragmatic mechanism for moving forward and creating flow, without getting bogged down in over analysis, excessive planning, or overly vision-driven collaboration. It won't always be the most appropriate tool - but increasingly I'm starting to believe that it should always be part of every organising toolkit - it is necessary if perhaps not sufficient.
I've often cynically suggested that 'management is the art of complaining that nobody is seeing the big picture even when there isn't one'. I was referring to the tendency for management as a profession to use their unique perspective across the organisation to exclude and manipulate rather than to enlighten. As a manager, if you find yourself saying 'you're not seeing the big picture' it's likely that you've failed to communicate or otherwise engage your staff I in a manner which highlights that perspective. If somebody was to pause and actually ask 'well what is the big picture?' you need to ask yourself if you could actually answer them and would you even be willing to spare the time to do so?
What does this have to do with workflow management? A lot, if you understand that I've always striven to see and articulate the big picture in all projects I've worked on. As an information or delivery architecture I have tried to ensure everybody knows how information or delivery processes respectively relate and flow through each other. This sort of work suits the analytical and architectural aspects of my personality but I'll be the first to admit that secret is know when to stop. The boundaries of architectural analysis - like the liberation idea of limited government - are what provide for effective allocation of resources, and release professional freedom and responsibility. My popular comments on the folly of 'seamlessness' in systems still stands and is also reflected in my analysis of management teams as cartels. It is the specific seams that you create in your delivery architecture which determine it's operating characteristics.
In many ways workflow management is the opposing and complementary force to architecture. To give a simple example of somebody I would call a workflow manager, picture a person who comes to a regular meeting you have been having for years. They proclaim to not know much about the work you are doing, and really can't provide any insight into how you departments or projects fit together. They seem almost proud of this absence of insight which immediately (and in a way rightfully - but we'll get to that another time) makes you hostile and cautious. Yet you know they have the support of the senior management team and a reputation for 'getting things down'.
But from the moment they start talking all they seem to be doing is creating work! You're already busy or at the very least don't see the value of the new and vague 'action items' you are receiving. But let's step back a little to this idea of 'creating work'. While nobody likes to do work that isn't of value there is a sense in which managers are in fact responsible for 'creating work'. Too much is often made of self-direction and taking personal responsibility. Indeed the ManageWithoutThem philosophy is a deep and practical manifestation of a market-based management model within firms. But at the end of the day it is more important that your management mechanisms have integrity. That is, beyond any particular management model what is most important is that the model is made explicit and the roles and responsibilities that cover both managers and non-managers are open and have actionable authority. It is that integrity which makes your operating model transparent and embeds the spirit of your claimed organisational values into your collaboration processes.
The implicit agreement between the workflow manager and the rest of the team is that the workflow manager is 'creating work' so that those 'doing work' can just focus on getting that work done. The implication here is that as long as people are doing the work that has been created, and doing it in a timely manner, they don’t' need to worry about the big picture. They don't need to know how everything fits together and they can leave at 5 o'clock each afternoon with no guilt and no unfinished business. This approach to work may not suit everybody but it certainly has a place in everybody's work life. After all, if you want to stay at work all-night you probably want to be working on your own pet projects anyway.
In the above example we are talking about managerial workflow management. Below the level is personal workflow management and above that level is organisation workflow management. In managerial workflow management it is the willingness for the workflow manager to take responsibility for the end-to-end result that makes this managerial workflow management. In managerial workflow management the manager is actually putting a process and themselves between other individual's performance and the end result. In fact, this sort of action is the hallmark of managerial workflow and management in general. To allow others to do 'work' without knowing the big picture adds tremendous value in complex environments.
| ||What is interesting is that Franklin was able to schedule hours of time labeled simply 'work'. Pre- my discovery of personal workflow management I would have found it pointless to schedule a vague activity like 'work' in my diary.|
Where the benefit of managerial workflow management is that you don't need to know the big picture in order to contribute, the benefit of personal workflow management is a little more, well, personal. David Allen, author of Getting Things Done, talks about 'mind like water'. He says the benefit of writing things down into his/a system is that you aren't thinking about the items when you should be doing them (as he said in his Cranky Middle Manager interview - 'there is a inverse relationship between on-your-mind and getting-done'). The accumulated benefit of this system is that you are always doing what you should be doing at the moment. All of this organising effort means that you can relax and just 'work'.
To make it even more personal than that, say you're at a point in your life where work isn't particularly important. Say you're burnt out, need a holiday, don't like your current assignment, have family problems at home you need to deal with - but need to work to pay the bills. Personal workflow management will allow you to get lost in work and get things down without being particularly interested in work. All of the office bickering, politics, and things you always wanted to change about work can actually be put on hold and ignored. This can be done for as long as you like - particularly if you give yourself time to record grips that you might one day want to fix in SomedayMaybe lists). You might even find that you like working this way or that it helps you meet career goals that have otherwise alluded you.
Before I move onto organisation workflow management I want to mention my objections to personal and managerial workflow. Managerial workflow annoyed me because the people seemed proud of not knowing technical issues (even when they actually did know), they created work, and they didn't offer anything in terms of a better fundamental understanding of the situation. Personal workflow to me seems like over organisation and seemed to reduce some of the passion and personal professionalism I felt about work. In both of these cases the grips I had are actually also the post powerful features of these two types of workflow. However, they are both potential negatives if workflow management is used exclusively without also applying architectural thinking and skillsets.
Finally, let's consider organisation workflow. This is workflow across multiple departments and even organisations. Because of its grounding in information technology minds this sort of workflow is often implemented as form/document management systems with associated approvals, business process orchestration, and integration with various computer systems. I love the idea of integration between systems but this all starts to sounds a little like automating a managerial and command-economy. Without the injection of a market-based coordination mindset organisation workflow becomes automated bureaucracy. Rather than market indicators and allowing the market to increase the transparency of your organisation, the over-litigation of existing organisational workflow management thinking may in fact cause the creation of workflow 'black markets' which drive effort off the systems and therefore reduce organisational transparency. IT systems should have their usability measured in terms of it being easier to use the system to do your job than it is not to use the system to do your job.
Social and collaborative web 2.0 sites such as Flickr, 43Things, myspace, etc give better clues as to what organisational workflow management should look like than say middleware software. I call these systems market-making technologies where the Web 2.0 terminology has become social networking technologies. I would suggest that social networking technologies are a subset of market-marking technologies.
The advantage of thinking of management as a technology means that you can apply criteria such as usability and enabler-of-transparency to improvements in that technology. Web 2.0 style tools that support workflow management processes at each level would enable more transactions to be carried out 'on the market' and therefore allow better information about the dynamics of the organisation to be gathered and published.
As the sophistication of automatic ontology generation tools improves, and as they better allow for additional manual explicit categorisation techniques and visualisations which allow architectural knowledge to contextualise the data we'll have somewhere to throw this market knowledge we are silently creating as people go about their daily work.
Monday, October 10, 2005
Cranky Middle Manager
Thanks Wayne! It was fun.
Saturday, August 27, 2005
Storytelling & Journey making
The MWT Model basically says 'What's so special about Leadership?' in a quite sarcastic way indeed. But that isn't to belittle the concept. What I'm saying is that the important thing is to be able to tell the difference between Quality leadership and... well, rubbish.
I'm not sure EPIC ADVISERS is 'particularly African' as Steve describes it. But I mean that in a good way in that it seems more universal to me. Sure, it's just a bunch of words. But it appears to be the right words for a change. There is a certain balance to this list of attributes which to me seems like it would be difficult to fake this type of leadership.
UPDATE: More detail here (pdf).
Thursday, August 25, 2005
I'll comment after I read it... But it's gotta be good
Monday, August 22, 2005
Smalltalk Tidbits, Industry Rants: XP debate
Wednesday, August 10, 2005
Seeing the big picture. Showing the little picture.
Some thoughts in the back of my mind as I develop estimates for a project I’m currently working on. All these numbers, contingencies, and risks. While I’m promoting market-based management and should be against ‘planning’ what I’m really all about are the mechanisms for separating good planning from bad planning (sort of). I'm also concerned with exposing what limited information, what limited controls and enablers, are actually defined by a schedule and a resource plan.
But as limited as a schedule and resource plan are, they are many orders of magnitude more interesting than an estimate. With all the effort to reduce (or at least record) ‘Assumptions’ an estimate is still, by definition, filled with assumptions. An estimate IS an assumption. I’m fortunate enough to be able to use some baseline productivity metrics which allows me to ignore huge chunks of the dynamics within the project for the purpose of my estimate. But one assumption I shouldn’t make is that people will in some way ‘follow’ the estimate.
When the estimate is complete it should be locked up in a box. Nobody needs to see this estimate. There should be 3 degrees of separation between this estimate and anything that 90% of the people on the project are doing at any particular time. If the project takes more resources than the estimate suggests the estimate is wrong - and yet, the estimate doesn’t manage the project at all. Nor does it offer any hints at all on how to manage the project. This breaks The New MWT Hierarchy but I’ll leave the risk analysis to the reader.
Some may ask “Shouldn’t you show people the estimate so that they can ‘see the big picture?’”. Certainly not. The estimate doesn’t show the big picture. Like I said it actually contains very little information. If you have a ‘big picture’ of your business model, or your project’s delivery architect, or a well crafted contract then these things should be published. In fact you are obliged to publish them to your employees. But an estimate is simply an assumption.
Management needs to show people the small picture. I’ve decided that this wonderful technology we call management is failing if people have nothing more than an estimate or a deadline at their disposal when they sit down to focus on their work. It’s also failing when they have a thousand contradictions in their head all relating to the same task. Like I always say “it’s easier to tell 10 people what to do than to be told what to do by 10 people”.
I’m all for big picture thinking and I really do think that an overall view is a vital component of management (these are the delivery and collaboration architectures I’m always going on about after all). But what I’m saying is that management is failing if that is all it has to offer.
I guess this is just another example of ‘the riddle of the stones’; where management thinking has become so muddled that it craves generalists such that the structure of the organisation doesn’t really matter. Preferably, mythical generalists who can apparently do just about anything with equal efectiveness but for some strange reason stay where they are put – and do what they are told. Much like a stone.
There is a contradiction here if I don’t add one other point. How can I be advocating market-based management and then suggest that the management system of an organisation needs to be responsible for the muddled thoughts of an individual sitting down to do work alone? But there is not contradiction. I’m just repeating, as always, that we are all a part of this management process. While that unavoidable hierarchy of responsibility always flows up, we are all integrated.
Too often I see layers upon layers of management and months of planning reduced to asking a strange little man in the corner who only got the task this morning why he isn’t finished yet.
Thursday, July 28, 2005
The McKinsey Quarterly: From push to pull: The next frontier of innovation
* Most companies now mobilize resources by deploying push systems, in the mistaken belief that they promote efficiency.
* Push systems—characterized by top-down, centralized, and rigid programs of previously specified tasks and behavior—hinder participation in the distributed networks that are now indispensable to competitive advantage.
* More versatile and far-reaching pull systems—characterized by modularly designed, decentralized platforms connecting a diverse array of participants—are now starting to emerge in a variety of arenas.
* As pull systems reach center stage, executives will have to reassess almost all aspects of the corporation."
Saturday, July 23, 2005
Josh Kaufman: Inside My Bald Head: The Personal MBA 40
I would also add Mintzberg's The Rise and Fall of Strategic Planning. So glad you included Economics in One Lesson (it's certainly on my recommended reading list but you'd expect that with my market-based ManageWithoutThem model).
Perhaps Mises' Human Action could be in the Doctorate programme. Adding some other classics like Bastiat's The Law might make it an open-MBA...?
Posted by: Matthew De George at July 24, 2005 01:07 AM"
Management Teams as Cartels
Before: Management Team as Cartel
After: Management Team with Governance
Annotations coming soon...
Friday, July 22, 2005
Harry Potter Book 7 Revealed *spoilers*
I haven’t read any of the Harry Potter books, but I have seen two of the movies and read a review of the latest book that contained ‘spoilers’. So it’s painfully obvious to me now what the final book will be about and what J.K. Rowling’s ultimate plan for our children actually is.
Before I get to what will appear in the final book let’s look at the cunning precedents that Rowling is establishing in our hearts and minds which will allow her to achieve her ultimate goal. Which it is now clear, is the corruption of children everywhere.
Look at how each new Potter release is accompanied by increasing amounts of security and miscommunication about details of the plot. For the final book it is expected that this secrecy will have been perfected. No reliable details of the plot will be available until half the world's children have already completed reading the book.
False rumours and extracts will appear on the Internet weeks before the release. It will be denied by Rowling but these rumours will have been started by Rowling herself. They will serve to render the impression that this is just another harmless children’s story that only a Pope would have objections to.
So why is this secrecy so important to Rowling. Because in the final Potter novel Harry’s true character will be revealed. Currently, the goodness of Harry rests on the fact that it is set up against the evil of “You-Know-Who” (Voldemont). You-Know-Who allegedly killed Harry’s parents when Harry was still a baby.
When I read that Dumbledore had been killed in the latest book it all became clear to me. Some may think that Dumbledore will just come back again in the next book like he did when he died in the Lord of the Rings movie – but I’m sorry Dumbledore is gone for good.
In fact it is Dumbledore’s death that finally draws Harry to the dark side. Yes; that’s right Harry will convert to the dark side of the force in the final book! He couldn’t save his parents, then he couldn't save his godfather, and then he couldn’t save Dumbledore. Only the dark side give will give him power over death. This is a power that he can’t live without.
But who really killed Harry’s parents? The story is that You-Know-Who couldn’t kill Harry. Why is that do you think is? We know now that it’s because You-Know-Who IS Harry. It was indeed ‘his mother’s love’ that saved Harry. His mother who helped turn Voldemort into Harry (making Voldemort ‘disappear’ except when Harry is around). Harry’s internal struggles being depicted in the physical world when Harry ‘fights’ Voldemort.
I wont spelt the rest of this theory out in detail because it’s actually quite obvious. But it should be noted that Harry has often been referred to as ‘the chosen one’. Those in the know believe that Harry will save the [re]public from dark magic. We all know that such prophecies can be misinterpreted...
Anyway. Enough of that. This is what Rowling has planned for your children to read…..
MWT Book Extract - Governance, Hierarchy, and the Delivery Architect
Hierarchies are powerful organising constructs. One of the assumptions people often make about the MWT Model is that if it is market-based it must also be against hierarchical organisation. This is not true as hierarchical organisation is an important feature of corporate governance. Without the overriding principle that the CEO and Board are ultimately responsible for the organisation’s performance (and the organisation's overall impact on society) there can be no corporate governance. The unavoidable hierarchy of responsibility draws a line from each employee, through their managers, directly to the Board.
It is the unflinching burden of this hierarchy of responsibility that often causes the best-seller lists for management books to be dominated by what are essentially self-help books for people in positions of power and responsibility. Indeed, much of the management profession has been developed to push this burden of responsibility down the hierarchy. This is different to delegation. Delegation, or rather the correct distribution of decision rights, is by definition always a positive contribution to the organisation’s effectiveness. Distribution of decision rights is in fact enabled through the hierarchy of responsibility. If a manager is ultimately responsible regardless of delegations then there is no point restating the managers responsibilities and calling it management. This is what subtlety occurs with Single Point Management (see Chapter xxx). In a sense, when I say 'management is the process of determining which decisions don't have to be made by consensus' I am also saying that management is the process of determining which decisions don't have to be made by the manager.
Management should always involve the organised delegation of responsibilities. You will often hear that you can delegate responsibility but not accountability (or something like that). This management truism is indeed true. What it is saying is that the manager is always accountability even though they have given the task to somebody else. The problem arrises when the one class within an organisation (in this case that class is the management class) has both the right to delegate and the right to judge capability. This violates the MWT principle to ‘make management one step removed from measurement’. Too often I have seen managers attribute their failure to 'unskilled resources' and too often this is the case when those same resources have been working for the manager for months or even years. Though not always the case in well matrixed organisations and project, managers are responsible for the capabilities of their people – so blaming your resources for failure is not an option.
Market-based management partially solves this problem by providing mechanisms for people to choose their managers. However, this is not an ideal solution as it will mean that truly challenging endeavours will never be resourced. Also, as discussed in Chapter xxx, competitive differentiation and alignment to strategy would be ineffective under a strictly market-based management model. In order to resource truly difficult endeavours and maintain a strategy of differentiation, you have to strictly follow the rule that if a subordinate is responsible then the manager is also responsible.
Due credit should be given to organisations who try to solve this governance problem with such mechanisms as '360 degree' assessments and other elements of a comprehensive performance management processes. In fact, even the very existence of a human resources department is supposed to provide a mechanism for resolving problems with managers who have taken advantage of the largely political relationship between the manager and the managed which allows their own failings to be exploited and reframed as leadership. However, the problem with 360 degree assessment and reliance on a separate human resources department is that these involve interventions. As mentioned in Chapter xxx, any management model which relies on interventions cannot improve corporate governance because managers control resource allocation and therefore they control which interventions are resourced. So in effect they control which interventions occur. If those resource allocations are ineffective (from the organisations perspective) the interventions simply wont occur and the risks to effective corporate governance will not be managed.
The New MWT Hierarchy
The New MWT Hierarchy reinforces the idea of an unavoidable hierarchy of responsibility. More importantly is provides a more comprehensive explanation of the forces which are already acting within the management hierarchy. The New MWT Hierarchy should be considered a management pattern (in the sense of Christopher Alexander's A Pattern Language as discussed in Chapter xxx). In the diagram for this pattern each of the olive green components are a different person performing a different role. It is important that these are physically different people. It is only then that the correct incentives are in place for the pattern to work.
However, some will correctly note that this is overkill for smaller organisations or projects. It is true that this pattern evolves too many people to be suitable for small organisations. However, it does more effectively represent the forces which need to be in place to govern the hierarchy. It is only because the risks are smaller in smaller organisations that roles can be combined into less resources. It may even be possible that the roles are combined into a single manager. This is of course exactly what the traditional view of a management hierarchy would suggest. But I believe that in all cases where the roles are combined a risk is introduced. It is only because management practices have developed an unquestioned value proposition unto themselves that this idea of risk management within the management model will be unintuitive to many. This is why risk management within the management model is such an important component of the MWT Model.
Note also that it is not just the size of the organisation that indicates the roles should be separated into different people. Other risks such as the combining of diverse capabilities with a new collaboration / delivery architecture also indicate that separate people in each role should be used. Also, any time when an independent project management firm is used to manage other firms the roles should be separate people (or perhaps separate firms).
It might also be the case that a strong general manager will require a separate delivery architect to supplement their general management skills with domain or task-specific skills. There is a long standing argument about whether a good manager can manage anything. The answer to this is 'it depends'. An understand of The New MWT Hierarchy allows the decision to be made by assessment of the managers skills in relation to the domains they are managing. The discussion on the relationship between the manager and delivery architect will make that clear.
The individual components of the diagram are introduced in the section below. As for all MWT collaboration architectures (as The New MWT Hierarchy is simply a generic collaboration architecture) in addition to the component descriptions a set of traversals across components will also be provided.
<--- continued --->
Tuesday, July 12, 2005
New MWT Hierarchy
Sunday, July 10, 2005
Naturual Law and Order
Even if you don't enjoy the content you could make a drinking game out of he number of times he says 'So to speak' :-)
Found in Mises media.
Friday, July 08, 2005
Why are programmers supposed to know everything?
To wish that programmers knew everything is generally a waste of time (how could they?). But I think this guy is onto something - I just don't yet know what it is. There is certainly something wrong with the way many IT people think the world works which comes out when they try to manage.
David Crow: Why software development is not only programming
Monday, July 04, 2005
Sarbanes-Oxley and Internal Markets
Sarbanes-Oxley is all about the retention of records. It started because some audit company is supposed to have shredded the audit records of one of their clients. If you look at the Mises Blog I think you will find one of the few references to the fact that the charges against the audit company have seen been dropped (Is this right? Check Mises Blog). However the ruling still exists and organisations are scurrying to comply with it.
The thing is Sarbanes-Oxley doesn't just stop at retention of records. The intension of the ruling includes both retention of records and assurances that the records are accurate. This bit is important and interesting. It means that audits are required at some regular interval to ensure that the records are accurate.
Let's take a simple example of asset records. Just as most organisations are struggling to keep simple records of the assets that they own, the Sarbanes-Oxley ruling says you have to audit the records to make sure they are accurate. So every three years you have to collect all the information about your assets again.
I have to be clear here; you can't just download the information from your asset register. The purpose of the audit is to ensure that the asset register is correct. So you need something to compare the information in the asset register to. So every three years you have to ask everybody in your organisation what assets they have - even if you think you already know. This is the only way you can make sure and prove that you already know.
While the intension is arguably good this is clearly ineffective. I also think it's not sustainable. Also, I think the risk here is that organisations can still fudge the audit. To take an extreme example, the organisation could fake all of the collected records by writing a small script which takes the asset register and turns it into emails. The script could throw in some mismatches so it looks realistic, the mismatches could be resolved, and the organisation would have compliance.
So in a way the law doesn’t really guarantee real compliance. This menas that eventually one of three things will happen. The most unlikely is that the government will decide not to interfere anymore. Alternatively, the intent of the law will be made more clear and additional laws will be created to cover individual cases of fraud (the typical approach of law propagation). Or lastly, the courts might shift the focus from ‘reporting requirements’ (what you have to submit) to ‘operating requirements’ (how your organisation actually has to work).
I'm betting on the last scenario where 'operating requirements' are imposed. And this is where technology-enabled markets come in. The scenario I'm going to describe is 5 to 10 years into the future. Even though the technologies largely exist it will take that long for the law, and our transition from command-based management models to market-based management models, to catch up.
A technology-enabled market approach to enforcing impending 'operating requirements' with the same intent as Sarbanes-Oxley would look like this...
--- To be continued ---