Techn@gerial

Edward Tufte is an information design specialist, his work is absolutely outstanding; he has written four wonderful books on information design and the presentation of information. Whilst browsing his site recently I stumbled upon this thread: Project Management Graphics (or Gantt Charts), which starts with a Tufte reader outlining their issues with using Gantt charts when dealing with a large project – an issue which I’m sure we’ve all encountered, printing 10’s of pages and gluing them together on an entire wall. Just to get a feel for the project’s timelines, dependencies and resource usage – Tufte offers a solution; a brilliant one at that.

  Say “no” to GanttEdward Tufte:

Most of the Gantt charts are analytically thin, too simple, and lack substantive detail. The charts should be more intense. At a minimum, the charts should be annotated–for example, with to-do lists at particular points on the grid. Costs might also be included in appropriate cells of the table….more.

For the project minded among you, I am very keen to hear your thoughts on Tufte’s design as well as what alternatives you might have to the ghastly Gantt.

OH.2008.05.15

Tweet This Post 

Design patterns are – to most established and successful software developers - reusable, known good starting points for specific applications in writing software.  They are proven, best answers to some of the most basic problems encountered when writing code.  The seminal  work on this subject is the eponymous 1994 Design Patterns or “Gang of four” book, which deals with design patterns for object orientated programming.  There are several types of pattern: constructional, structural and behavioural and latterly even more.  They have names such as Singleton, Facade and Mediator.  In simple terms they provide a way to stop software engineers from assessing and reinventing common solutions time and time again; if it needs to roll, these are the plans for the wheel.

My experience in working in systems and software development has often required the same answers to the same questions.  How do requirements get written? How should the development process work?  How do we prioritise our projects?  Why can’t we deliver on time and to budget?  How do we maintain our software?  Fundamentally, the answers to these have been, in essence, the same, the foundational structure of  the answers being common, from large global businesses to small niche players.

Whilst large scale frameworks like ITIL and Prince can provide best practise in terms of execution, I am not sure they provide the actual pattern, more the instructions and rules.  They seem to err away somewhat from the foundational definition, or even assume it is already in place.  This enables generic suitability, but what role could specific patterns for these common, business challenges play.?  What would a prioritisation pattern look like?  What would an estimating pattern look like?  A peer review pattern…

Some formative work on this subject has been done, certainly in the 90’s, but there is little published specifically for these more process based patterns;  the capturing of wisdom to enable new businesses to learn from the established.  To have some of these patterns would save the effort and waste of rediscovering how to fundamentally operate as the start-up spark fades and maturity needs to prevail.  I am wondering where these patterns are, perhaps they are locked up in the “IP” of integrators and consultants, but surely there is enough experience out there to bring them into the open.

More to follow…

Tweet This Post 

Having refreshed my IT and being able to use my new personal PC without ear defenders, I have been catching up on some reading.  Seth Godin has a great snippet on his blog about the relationship between The Story and The Work.

I’m not sure if it is an instinctive behaviour on account of the highly technical environments I have worked in, but this concept resonates with me strongly; I need to see The Story in most things I undertake.  Moreso, I also need to see The Story in a situation to fully engage in changing the aspects of it that may not be relevant or appropriate. 

I guess The Story is the sum of the “narrative” parts of the solution to any given problem or challenge; the root or “beginning”, the situation or the “middle” and the solution/vision or the “end”.  Any one of these elements will have domain experts that can ensure you have everything you need to understand each part.  However, to be able to rewrite things the way they should be or the way you want them, you have to be able to see them all together to begin to visualise or “write” the possibilities and variations available to you.

Seth’s Story may be slightly different to mine, given his particular focus, but the concept is portable.  If The Story is a good one, something that will sit easily with others, then this helps making The Work all the easier when coming to getting it done.

Tweet This Post 

In several previous posts I have alluded to the importance of assessing the capability of your workforce.  Having worked in several software and service product companies, the emphasis is somewhat different depending on market and the need for speed, but generally, knowing as much as you can about the skills your people have is extremely important.

Consider my previous article “Mind the gap!”, where the capability is irregular.  This shape, i.e the quantities of differently skilled people you have at your disposal in different areas, may be completely intentional.  However, it is likley to bear a significant burden of constriction, in places,  due to attrition and, perhaps less so, oversupply due to failed initiatives or declining products/markets.

When it comes to getting strategic about your future direction, understanding how this shape needs to look is a key pointer to setting budgets and engaging your management teams in gearing up for the strategic plans you have. 

Continue reading »

Tweet This Post 

Is it a project?  Is it a programme?  This is a topic that is occupying my mind this week, on many levels.  There is a good short paper, Managing Successful Strategic Programmes to be found at www.nixonbrooke.com it addresses the fundamental differences between a programme and a project and provides some useful help for determining the difference.  The paper, by Ian Jones (some relation) can be found here.

On a more fundamental basis, I need to make some deterministic evaluations of what makes a Strategic Programme Manager rather than a well tooled Project Manager…

Tweet This Post 

I recently bought an iPod Touch and wanted to try out the device in writing a post on my blog. Although I like the original skin on my PC, it was a little busy on the small iPod screen. iWPhone to the rescue; an iPod Touch/iPhone friendly skin and client detect plug-in for Wordpress.

Installed and working fine, here is a pic I took earlier today with it in action on the actual device. Much neater although the content outside the main artcles is no longer available.

I then set about writing this post on my iPod. No problems and the “fat finger” word replacement is very good.

All in all a good device for short updates. Expect to see some more…

Tweet This Post 

In the UK, specifically in London, there are few warnings more diluted than this one.  It is subconsciously nodded at by millions of commuters every day, doubtlessly some people still don’t heed it and twist their ankles or worse. 

I’d like to look at a different gap, related to businesses and their needs in terms of work and things that need to be done. 

All businesses have a whole stack of work that needs doing.  I’ll subdivide this work, crudely,  into four types:

• Explicit needs – Things that absolutely must get done to stay in business
• Implicit needs – Things that should be done to stay on top of your market
• Nice to haves – Things that may add value or differentiation but are difficult to justify or deliver
• Dreams – Things that may add value or differentiation but are impossible or unrealistic to deliver

Project X is a piece of work that must be delivered.  However, depending on who you ask in the business, the degree of certainty about Project X being critical is mixed.  Some think it would be nice to have, others think it is a dream.  In an unconstrained world, where you had the world’s experts at your fingertips, that wouldn’t matter.  But in our world, the real world, you will have a limited and often variable capability with which to operate.  This capability is not usually capable of servicing the entire “Need Stack”.  The gap between the top of the Need Stack and the top of the Capability is what I call the Expectation Gap. 

In a growing and energietic business it is often difficult to explain this gap without getting into hot water with someone in senior management.  But it is more complicated than just a shortfall in resource.  The variable nature of your capability is also a major constraint in your ability to execute and deliver against the Need Stack.  Bottlenecks will exist, usually in your most precious resources and as such throughput in terms of projects can be seriously limited.

One temptation that many businesses will entertain is to grow the capability, either using external resources or moving oversupply to undersupply if possible, internally.  Some businesses will outsource entire functions or buy in third party products to help automate or fill in shortfalls.  Some of these will work with varying degrees of success (see earlier posts about outsourcing in software development), but what is actually being achieved?

Growth without an eye on benefit will ensure costly investments in terms of cash and opportunity will be closely followed by contraction and lost market position when projects fail to deliver. Therefore, growth must be on the basis of value and as we saw earlier, opinions differ on the value Project X will deliver.  So how do you pinpoint where Project X is in the Need Stack?

The simple answer is  analysis.  A meaningful measure of thought, research, validation and planning; all the ingredients of a coherent and capable business case.   This will surmount the first obstacle of knowing where things are in terms of relative priority.  You then have a working “reality filter” through which to pass all your needs and aid your decision making process or people.

Beyond that, there is still the capability issue.  This requires a more difficult culture shift to overcome; one that will be unpopular in some quarters of your business.  Acceptance that your capability is limited, or in some cases strangulated, is key to you deciding what projects you assign your capabilty to.  Secondly, when you know the order and status of your projects, you will more clearly see where you are lacking in capabilty and as such you can grow these areas of your business to accommodate the work you know will add value.

Managing the Expectation Gap is a key activity for any business no matter how large or small. It does however, cause frustration, argument and a level of campaigning for the work your people want to undertake.  Despite this level of perceived disruption, surely it is better to “argue the toss” and make the right decision for the business, rather than leave it to one point of view and a fait accompli outcome that may cost you more than just money in the long run.

Tweet This Post 

The next rev of TaskClerk was released at the weekend, you can get the details here. Excellent work John, thank you.

Tweet This Post 

Sometimes when people leave a job there is a somewhat mawkish tendancy to peruse their websites, or snoop about how things are going at the old company.  Usually, in time this fades and it becomes an ex-job and old colleagues become friends or are assigned to LinkedIn.

It still amazes me though that some find it impossible to move on and leave the past behind them and their old company to the future without them.  Why is that?  Unfinished business?  Unstable psychology?  Fascinating.

Tweet This Post 

I haven’t been on a training course since at least 2000.  So a residential course held at a pleasant hotel in rural Oxfordshire seemed like a good prospect.  Actually, I didn’t have any choice.  With a collection of colleagues, I entered into the training with a mild suspicion, expecting either probing assessments or hackneyed concepts and “models”.  Actually the reality was quite different.  DDA Consulting offered a lot more than that.  The exercises were abstract, and therefore easy to become absorbed in and the learning was all delivered via your own realisation that you aren’t quite as clever as you think (of course, not me, I am an ENTJ and am therefore extremely intuitive and could see all this coming).  Yah right!  (I used to be an INTJ)

There were failures, wasted effort, great short-cuts discarded like smoked cigarettes; all these, and our hand in them, helped the messages soak in slowly and in a way that was very thought provoking but not challenging and not, in any way, detrimental.  Needless to say, everyone was soon hooked and having a great time.  The other good thing was the team-work shone through and despite my expectations of egotistical bloodlettings, there were none, in fact there was very little interpersonal tension at all, which was amazing!

It was very worthwhile and I would wholly recommend David and his colleagues to anyone wishing to become more personally effective and also validate their learning and opinions of themselves, and the world, to date.

Tweet This Post