Various posts on this blog have discussed the vagaries of planning for software development projects. This post goes a little further than that and will explain what can happen when you get good at delivery and confidence grows in your ability to deliver. This may not be easy to read if you are currently delivering successfully.
There are many things in life, day to day, that we take for granted; especially in the developed world. Clean water, available energy, medicine, longevity, the list is enormous. However, when one of these "certainties" is disrupted, for whatever reason, the impact can be quite disastrous. On the whole, disruption to these mostly (seemingly)mundane amenities is quite rare, but to those that are impacted, see New Orleans storm refugees, Gloucestershire flood victims and New Yorkers during their prolonged power outage, these outages of normal function are extraordinarily disabling.
On a more personal level, the day to day can be thrown into disarray by a mere or inch of snow or a flat car battery. Depending on your personal circumstances, the things you take for granted are only really evident when they are momentarily, or sometimes permanently lost. Clearly a software project lesson is upon us…
Product and service roadmaps are notoriously hot topics in most software or technology businesses. They are there to represent the aspirations and communicable plans a business wants to surface and use to keep their customers and partners engaged. There is no doubt that they are an essential aspect of demonstrating and evaluating your delivery capability but getting them right and keeping them meaningful is a challenge.
There is no doubt that agile development techniques (of which there are several, Scrum, XP, Lean etc.) are an excellent way to empower a development team and enable them to really engage in the process of delivering software. I will focus, such that I need to, on scrum; my preference. These techniques delegate responsibility (not accountability) to the technical team, led by a scrum master. This enables them to decide what is done when and how these decisions are made relating to any given set or state of the requirements. The daily scrum meeting assigns priorities for work and addresses issues arising. It is a technical forum where the team frankly raise and discuss their issues and experiences. Scrum is usually composed of a series of sprints where requirements/features/stories (use cases) are solved in design and code. But how do you surface this kind of project within your business and how do you report on the unknown?
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
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.
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:
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.
I have been wrestling with a specific issue of how to present a view of how a project led business needs to be “knitted” together to ensure delivery. I am sure that there is “best practice” material for this but it has to be specific.
I decided on four layers:
|
Authority Decisions informed by the Business Strategy and capability Management Control and governance of the execution of business decisions Lifecycle Frameworks where tasks are organised to deliver in the specific context of the business Process Tasks with assigned roles and responsibilities amongst your people and partners |
With this simple, top down model it should possible to define and explain an integrated business management concept that will support a project led approach to delivery.
I’ve never really used the project management templates in Visio until recently. I was looking for a non-MSProject tool to build a gantt chart and something more illustrative than just a spreadhseet. The Project Schedule template set contains an item called a Gantt Chart Frame. It prompts for the number of tasks and the default timescale for the chart. You can then fill in the blanks and even add milestones and dependencies. The output is pretty good.
So why not use MSProject? Well, this picture isn’t a project plan, so if you don’t want to legitimize what is a forecast or a “guess-timate” it may help illustrate your thinking.
Why is it so difficult to accurately determine the path of any given software development project? What are the constituent aspects that create uncertainty and inject risk? Why do software development projects invariably end up exasperating senior management? Why do they slip?
Quite simply, software development projects are different to other projects. The mass of moving parts, different people, legacy support and integration and a whole range of other components and dependencies can be mind boggling.
Software is intrinsically complex. To the untrained eye, code and software architecture is quite literally like a foreign language. It can be learnt however, and some people have a natural aptitude for the work. But, as with any learnt skill, capability comes in degrees, people vary enormously and in this particular field of work, this variation makes a big difference when trying to plan for delivery. This article outlines some of these variables and how to prevent them being an issue.
Continue Reading »
Software project entropy
Tweet This Post links powered by Tweet This v1.3.2, a WordPress plugin for Twitter.
![[Post to Twitter]](http://www.matanza.net/wp-content/plugins/tweet-this/icons/tt-twitter.png){kind=icon}