Requirements Ridicle - the other requirements denial

There is another type of requirements denial. I've noticed this in the past but I didn't know how common the phenomenon was. I think I'll call it Requirements Ridicule. It's probably an indication of more substantial communication issues between the client and the vendor but Requirements Ridicule is a symptom that is easy to spot.

Requirements Ridicule is when the client requests a requirement and the vendor, rather than try to under the drivers for the requirements and work through any communication issues, immediately interprets the requirement as the most ridiculous nonsensical self-contradicting statement that the client could have possible meant. The vendor then immediately says the requirement doesn’t make sense.

For most IT projects, where the client isn't an expert in requirements analysis or software development, this practice is entirely inappropriate. The client will still want the requirement to be met; but it's likely that it's either not the true requirement or has been misinterpreted by the vendor. As the vendor isn’t trying to determine the real requirement what is actually implemented will most likely be ridiculous.

Not only is the implementation of the requirement likely to be ridiculous but the vendor will be out to prove that the requirement is ridiculous. Developers will decide they are not responsible for implementing this requirement with any degree of quality because it is inherently ridiculous. In fact the long suffering developer (who in large projects isn't to blame because they didn't collect the requirements) will tell their manager that the requirement is probably not what the client really wants but the manager tell them to develop it anyway.

In the end, developers wont consider that deadlines apply to the implementation of this requirement because it is so inherently ridiculous that of course it's going to take a long time to implement! I'm not blaming developers here, by the way. I rarely condemn developers as they have already been condemned to a life of confusion and frustration working for bad IT managers.

A business transformation checklist

From an unlikely source perhaps (the 'Army Enterprise Integration Oversite Office') we see an interesting high-level checklist for business transformation. The fact that it is in a circle doesn't really add any value but it's pretty. And it's a good starting point for planning a business transformation programme in a government organisation...

It also provides an interesting quote about where the risks might be for enterprise resource planning (ERP) implementations:

In a survey of CEOs who had recently implemented ERPs, 73% identified cultural and organization factors as the risks (high or very high risk), compared to 41% identifying business and process factors as carrying an equivalent risk, and 27% identifying the same level of risk for technology and system factors 22. These results reveal the importance of investing budget and resources for transformation management services for all phases of an ERP or CBPI program. An effective transformation management program increases the likelihood that a project will be completed successfully and anticipated benefits are delivered.

"Requirements Denial"

"Because no-one takes an independent view of whether the user requirements have been correctly stated, and whether the project [as] built is going to satisfy them, many projects contain a huge but undefined and unrecognized element of risk. This doesn’t mean that they will all fail, but when they do, the results can be spectacular... This failure is known as 'requirements denial'"

Top-Consultant.com - Global Opportunities in Consulting

Darrell Norton's Blog [MVP] : Modeling Artifacts (different ways of modeling)

Darrell Norton's Blog [MVP] : Modeling Artifacts (different ways of modeling): "Modeling Artifacts (different ways of modeling)

Scott Ambler has a great page that lists 35 modeling artifact types. The page links to summary descriptions of a wide variety of modeling artifacts. Each page describes the artifact, provides an example or two, and provides links to suggested resources. In this list he also indicates if the technique is simple enough for stakeholders to learn, whether it is usually a paper-based artifact, whether he suggests creating it on a whiteboard, and what type of software he would consider using to create and maintain it. "

Single point management #2

I’ve never really been a fan of what I call single point management (SPM). This is where a manager thinks that just because they have responsibility for something that means that everything relating to that function must ‘go through’ or ‘be approved’ by them.

This approach is okay for taking control of a situation or assessing the current state but it doesn’t really do anything for the organisation or the advancement of management theory.

But my main problem with single point management isn’t that it inefficient and completely ignores advances in communication tools (or even legacy communication tools like CC’ing emails). My main problem with the single point management approach is its effect on governance.

I tend to define governance in very simple terms as ‘what managers the managers’. Under this definition of governance the single point management approach gives a manager the opportunity to avoid responsibility.

Take for example the case where a quality manager says ‘I’m the quality manager so all work products must come to me for review’. In the event that a defective product is released into production or to the marker the quality manager is, by definition, responsible. However, by using a single point management approach the quality manager will undoubtedly have a way of avoiding responsibility. The chances are that the quality manager can point to an instance where a work product was not submitted for review and approval. Alternatively, the quality manager can claim that they didn’t have time to review and approve all the work products being sent to them.

So while the single point management approach might be an effective strategy for the individual manager it is actually bad management. In this case the forces that are actually managing the organisation (eg. ‘what collaborating individuals share’) are those of poor governance.

Like I’ve said ‘Management by inspecting - Governance by sampling’. Managers must ensure they met their responsibilities without reviewing all work products.

Cities as Information Management; Management as Information Management

I’m finally getting around to reading Steven Johnson’s Emergence. I understand I’m late to the party here but I figured Emergence would be something that I would agree with too much for me to learn anything from. I tend to agree with (though not always follow) the Jason Pettus Healthy Reading Pyramid (TM) in this regard.

Emergence has turned out to be very agreeable reading. Not just because I agree with most of it intuitively already, but because it’s so well written and the examples it uses feel classic and timeless.

There are also lots of things in the book that relate to ManageWithoutThem core principles. In fact, back when I was tinkering with these ideas from a management perspective, Johnson was actually writing his more general book on Emergence!

I want to quote a couple of paragraphs from Emergence. They are not the most interesting or enlightening but they are the most related to ManageWithoutThem. Specifically they relate to:

• Organisational Usability. This come from idea that people need to use the resources provided by the organisation just as much as the organisation uses the people in the organisation. This applies to both people using the organisation externally and internally. Organisational usability takes the metaphor of good web design (for example) and apply them to the organisation. Use or frame, consistency of branding, ‘related items’ links, recommendations, etc all have a metaphor in actual organisation of companies.

• Information management IS management. This refers to the fact that while we tend to trying to find new things that we need to manage all the time – i.e. WHAT we manage (people, risks, issues, knowledge, customers, supply chains, etc) - we don’t often change HOW we manage. ManageWithoutThem focuses exclusively on that transformation of HOW we manage. One important component of that is the need not to manage information but to manage BY information.

The passages below, taken from Emergence, touches on both of these ideas from the perspective of cities. They also show how Emergences is all about the same self-organising forces that drive the ManageWitouthThem model.

There are manifest purposes to a city – reasons for being that its citizens are usually aware of: they come for the protection of the walled city, or the open trade of the marketplace. But cities have a latent purpose as well: to function as information storage and retrieval devices. Cities were creating user-friendly interfaces thousands of years before anyone even dreamed of digital computers. Cities bring minds together and put them into coherent slots. Cobblers gather near other cobblers, and button makers near other button makers. Ideas and good flow readily within these clusters, leading to productive cross-pollination, ensuring that good ideas don’t die out in rural isolation…

And another from the same chapter...

The nieghtboorhood system of the city functions as a kind of user interface for the same reason that traditional computer interfaces do: there are limits to how much information our brains can handle at any given time. We need visual interfaces on our desktop computers because the sheer quantity of information store on our hand drives – not to mention on the Net itself – greatly exceeds the carrying capacity of the human mind. Cities are a solution to a comparable problem, both on the level of the collective and the individual. Cities store and transmit useful new ideas to the wider population ensuring that powerful new technologies don’t disappear once they’ve been invented. But the self-organizing clusters of neighbourhoods also serve to make cities more intelligible to the individuals who inhabit them – as we saw in the case of our time-travelling Florentine. The specialisation of the city makes it smarter, more useful for its inhabitants. And the extraordinary thing again is that this learning emerges without anyone being aware of it. Information management – subduing the complexity of a large-scale human settlement – is the latent purpose of a city, because when cities come into being their inhabitants are driven by other motives, such as safety or trade.

Emergence is recommended reading for any manager.

No ID for IT

Australian IT - Tech courses in trouble (Simon Hayes, JUNE 14, 2005): "Bond University decided last week that the faculty of information technology had to go, and it was dumped with little fanfare and even less publicity."

I spend my working life implementing systems that support businesses or government organisations. Don't get me wrong - I do understand that information technology must support business or government activities. In the commercial world there isn't a lot of room for technology for technology’s sake. And although it’s rarely managed well, the business world already understands research and development, and commercialising innovation, so there is already a place for ‘pure’ IT in business.

However, the thought of universities removing the IT faculty altogether and making it 'part of business' is ridiculous and risky. Even before this move I have noticed a trend towards second year IT students being unable do perform simple programming tasks. University courses are already filling their information technology courses with business subject at the expense of IT knowledge.

There is tremendous room for improvement in IT courses. But giving up and simply teaching business or general management is not the answer. IT courses could benefit from aligning to the huge diversity of IT roles already within the IT industry that aren't addressed by their courses. There are few IT courses that will help you be a 'solution architect', 'delivery architect', 'enterprise architect', 'business analyst' (at a senior, business-industry-focused level), 'Programme Director' (with specific IT industry knowledge), etc...

The article I've linked to references a trend downwards in enrolments in IT courses. Other reports are showing an increasing demand for IT professionals. While this might the result of a phase shifted demand and supply cycle that isn't the only interpretation. My guess is that the already existing trends of dumbing down IT to include too much business or General Management for Dummies actually means that non-IT graduates are more valuable to the market.

If universities are serious about taking on the challenge of providing enough skilled resources to the IT industry they can't give in just because nobody wants to enrol in their courses. To met their obligations to society the universities need to ensure their courses are of a high enough quality to make students want to enrol. Part of a student’s assessment of quality is if the course gives them more of a chance of a fruitful IT career than hours of tinkering and a couple of IT contracts won on the strength of their web site.

Lastly, the strict discipline of separating (and yet aligning) responsibilities that is required to successfully implement information system is actually something that the business world could learn from. I call this discipline 'architecting' but even within IT circles references to 'architecture' tend to be taken to be technically focused. And this is even more reason to allow IT to have it's own faculty. We have no much to learn.

The Management Benefits of Telecommuting

“We're empowering them to be as close to being their own boss as someone can be and still get their paycheque. So when that person begins self-supervising the manager now is relieved from a lot of the hour-by- hour, day-by-day direction. I mean they’re still in touch with these people by phone and email and occasionally in person but they really see a dramatic change in just the simple issue of how they spend their time during the week. Their spending less time fighting fires, less time running into people in the hallway, and more time doing the kinds of advanced planning and thinking that presumably draw on the skills that got them into that manager's job.

The other thing that I often here from managers – and this is kind of a revelation to them – even the most anti-telecommuting managers end up coming back saying that managing people from a distance has made them better managers of the people who are in the office. In the sense that all the management 101 skills that we've said for years managers should be doing. That is, setting standards, giving feedback, doing development plans – all that basic stuff that managers could avoid through the luxury of close contact - they now have to do when they are managing remotely. And once they begin doing it with their remote staffs they can't help but doing with their in-office staffs as well.

The double benefit is not only this notion of the gift of free time but they become more disciplined managers, and more effective managers of their office workers as well.”

Gil Gordon interviewed on ‘The Cranky Middle Manager Show #2’

Additional notes on the 'Mythical Management Team' book chapter

Another problem with the idea of a management team is that they will determine rank order priority for activities within the organisation. This is actually perfectly reasonable behaviour and not necessarily harmful to the organisation. After all, some projects or business units will necessarily require priority at some point in their lifetime.

The problem is that the management team operates in terms of allocating ‘the best’ resources. They simply don’t have the time or inclination to focus on any others. That is because conflict in resource allocation will tend to be over the best resources. The management team is unlikely to be able to make as accurate decisions around fitness of resources – that is fitness to purpose.

So the management team, by placing projects or business units in ordinal priority will tend to move the best resources from assignment to assignment with little regard to finding the best fit for resources. One outcome of this are that the best resources tend to develop behaviours that match their transient work life (including ignoring important feedback loops). There is a second more damaging outcome.

The second result of an organisation which focuses on allocation of the best resources – which is the natural result of a ‘cohesive management team’ – is that resource allocation will tend to be at the expense of other projects or business units.

You might say that this is always the case. I start this book with the observation that doing one thing is necessarily not doing another. This is the opportunity cost lesson from economics. However, economics also teaches us about comparative advantage.

So resources should be put to use in the work that they are comparatively more effective than other resources. Applying ‘the best’ to each situation is like assuming that the man on the island (in the above description of comparative advantage) doesn’t have an incentive to work with the second man. In reality the organisation will perform better if the concept of the best resources is replaced with the concept of ‘the best fit’.

As an aside, the focus on the best resources is actually the result of personal risk management behaviours which are developed by the management team. By focusing on the best resources there is a change that the most appropriate work allocation wont occur. It is also likely (as I’m trying to prove) that the organisation will suffer. However, the risk that an individual manager might make an allocation which is seriously flawed is actually much lower. After all, the best resources should be able to perform better than average in most situations within a particular industry.

The problem is a management team cannot make these types of decisions day-to-day. But if they are forced to work as a team what else should they do. In fact, if you are trying to be a team player and you are in a management team you need to be willing to share your resources. Even if you know the that the best fit is for a resource to stay with you it doesn’t matter. You must be seen to give up your best resources for the higher priority problem. This is another case where management fads such as ‘teamwork’ work for everybody except groups of managers.

Priorities change. This is true because of legitimate changes in the competitive environment. But I have a feeling that there is another force at work. Priorities change because as inappropriate resource allocation continue other projects / business units are put at risk...

It all comes together with leadership and ethics

In an unmanaged environment the difference between leadership and dissent is a matter of position. In an unmanaged organisation there is no mechanism to tell the difference between a good manager and a successful manager. Without good management there is no ethical way to distinguish between competent and incompetent employees.