...recent feedback from an in-house "Managing Digital Projects" course that I ran in November.

Mark Stringer is an excellent, engaging and very knowledgeable trainer.  I really enjoyed the course and it has given me a lot t think about.  His analysis of the market dynamics was spot on, and his suggestions for moving forward very perceptive.  A lot of his techniques will work well in project management more generally as well as in digital project management.

Agile life-cycle management tools. My main experience has been with Jira, and it's OK for issue management, e.g. Tracking the status of an issue.

What it's rubbish at is backlog management - keeping track of a backlog, prioritising a backlog. Things I would really like to know:

How much work is there in a project?

How much work was there in this project yesterday? Show me a graph of how work on that project got added.

It would also be great to see some animations of how the project started, how it got bigger and how it got finished.

I'd also like end to end time to be a first class view. So on every issue, the first thing that you see is how long it's taken so far - but also, how long it's expected to take based on previous stories/defects/features.

Waiting - how long has this story hung around not being worked on? Again, just like end-to-end time, this should be immediately obvious for any issue.

Anybody got any suggestions - anybody know a tool that lets you do all these things?

When all work is treated the same, and perhaps called by a single type, there is likely to be greater variation in size, effort, risk, or other factors. By breaking out work by specific type, it is possible to treat different types differently and to provide greater predictability.

Kanban - David J. Anderson http://www.amazon.co.uk/gp/aw/d/0984521402/ref=mp_s_a_1?qid=1317465409&sr=8-1
Sent from my BlackBerry® wireless device

Within a couple of years, a template for writing user stories had emerged from the community in London.

As a , I want a , in order to

The use of this template greatly standardised the writing of user stories. One of the creators of this approach, Tim McKinnon, reported to me in 2008 that he now had data to show that the average user story was 1.2 days of effort and the spread of variation was a half-day to about four days.

Kanban - David J. Anderson http://www.amazon.co.uk/gp/aw/d/0984521402/ref=mp_s_a_1?qid=1317465409&sr=8-1
Sent from my BlackBerry® wireless device

Sent from my BlackBerry® wireless device

I've just read and article in the Guardian about how difficult it is to recruit software developers "The problem with recruitment for software jobs ... is you". There's this weird section where he says that finding CV's should be a “beauty parade.”

Recruitment should be a beauty parade. It should be a, wonderful, magical process of just having a procession of dynamic and enriched individuals parading in front of an employer blowing people away with their awesome coding skills and fascinating personalities.

What I was thinking was “well, a beauty pageant is a pretty horrible thing. It basically arises in societies where there is so little social mobility that women have to resort to taking nearly all their clothes off and parading up and down in front of dodgy D-list celebrities in the hope of getting any kind of career advancement.”

Why isn't searching for developers at the moment a beauty contest? The author of this article, Matthew Baxter-Reynolds curiously blames the recruitment agents and the developers themselves for refusing to don their metaphorical swimwear for pretty obscure reasons, like not paying attention to careers advice from their teachers when they were at school. But surely, the truth is that at the moment, things just aren't that desperate for skilled software developers. The only time you're going to get this kind of awful parade is when there are very few jobs and a large number of well-qualified people who are desperate to fill them. Actually, the last time that I can remember that there really was a jobs crisis in IT – after the first internet bust, the CV's and agency system really did fail for everybody, for agents, developers and and employers. For the employers, all the CV's were riddled with lies, or it was impossible to detect the truthful ones, because everybody would say anything to get a job.  For the candidates, you could send out maybe a hundred CV's to potential employers and not even get an interview.  It might well come to that again. We live in changeable times to say the least, but we aren't there just yet.

So why aren't developers wobbling down that catwalk in high heels and talking about their love of world peace and their desire to look after animals? If the companies that Matt is trying to staff are doing interesting, challenging work and paying quite well as he claim surely people should be parading themselves to work there. But they're not. This leaves us with a few possibilities either developers are really stupid or they know that the deal that's being offered isn't that great.

In my experience, IT contractors that command up to £750 a day pay rates aren't stupid, they may have many failings, but as a group I've dealt with quite a lot, stupidity isn't the adjective that immediately leaps to mind. That leaves us with the deal not being that great. And it probably isn't. My guess is that they're being offered 75%-80% of the going rate to work in a situation where's it far less than certain they will even get paid. It's also pretty certain that they won't be kept on for as long as they might be if they working, say, for a big, dumb, merchant bank, where you might work on a “temporary” contract for years. If they're being taken on as permanent staff, again, the salaries (and certainly the benefits packages) are probably lower than for the big organisations, so the only incentive you can really offer them is shares in the company, and I'll that's exactly what the venture capitalists who fund these “start up” companies expressly forbid.

So what's the solution? Well there are three that I can think of. The first, which probably isn't that palatable is to up the offer so that it starts to look more like a million pounds and a diamond tiara. If your day rates were genuinely competitive (at current rates, over £750 a day), and you let it be known that you wanted typographically beautified CV's, that is what you would get. As I said developers aren't stupid, they can pay a graphic designer to beautify a CV if that's really required to get the moula. Actually, no, it still might be a bit of a struggle, because one area where such developers are, if not stupid, then certainly obstinate is in insisting that that the content of their CV should be what matters rather than how it looks.  This is the same reason why they tend to be deeply distrustful of anybody in a suit.

The second possible solution, is to offer what you're offering to people who might think it is a million bucks and a diamond tiara – recent graduates. There are some very bright graduates out there, who probably could provide you with exactly what you need from a developer on a start up – enthusiasm, energy, a just-do-it attitude and a likelihood to hang around for eighteen months to two years at wages below market rates. But you need to find them. One way to do that is to take in interns. If you're going to do that, my inner circle tips, having managed an intern programme for Xerox are 1) don't hire computer scientists as interns – hire the brightest history or philosophy graduates that you can find and 2) pay them, don't take the ones who can afford to do it because daddy's rich.

There is a third option which is to de-risk the situation for both you as a company and the developers that are going to work for it. How about actually getting to know the community of developers that are working with the skills that you want to hire and let them get to know you. If developers get to know you and your company, if during the course of a series of meetings, chats, drinks, they get to see that your company really is doing something interesting and innovative and isn't going to go away any time soon, if they also get to see that you, and your colleagues that run the company, and that work for it, aren't arse holes, then they will be much more motivated to work for you. Similarly, if you actually turn up to some of these talks, and mingle with the attendees in the pub afterwards, you'll get to find out all kinds of things. Is the money you're offering competitive? Who are the really good people who it would be worth hiring, even at twice the money you're offering? Also, who are the arse holes? Actually, this kind of networking is very similar to what is classically advised as they way to come up with good negotiated agreements in such books as “Getting to Yes.” By socialising with the people who you're looking to get a negotiated agreement with (e.g. hire) you're “exploring their value landscape”. For example, it may be that lots of developers will sign up to work for you if you can guarantee that they'll always get to use the most recent version of the code – or even a certain source code control system or editor.

And there is at least one recruitment agent that I know of who is doing this – BarryCranford, who has been working tirelessly over a series of years to put together the London Java Community, organising talks and events and in the process getting to know a ton about what's going on in Java development in London, who's doing it, who's good at it and who to avoid. I'm not sure where and why Barry deciding to approach things in the way that he's doing them, but whether he knows it or not, he's essentially putting into practice the wisdom that's outlined in the classic article on how to get a job through connections “The Strength of Weak Ties” by Mark Granovetter and in new books on the science of connections.

How do I know about what Barry's up to? Why would I recommend Barry? Because I know him through a friend and former colleague...

"Best tutor by far - it would be amazing if every tutor had his energy."

"Interesting, thought-provoking, enjoyable, many useful tips/guidelines". 

http://www.train4publishing.co.uk/guideto/electronic/project.php

Can somebody please tell me what's wrong with this picture? One Sunday afternoon (yes, I was thinking about this stuff at the weekend) I found myself going off on my own, off-piste.  Trying to explain to myself, and thereafter, possibly explain to others why software projects have the kind of life cycle and experience that they do.  I've read Freedom from Command and Control by John Seddon and really like his distinction between "Value Demand" and "Failure Demand." 

This is my gloss on Seddon, and it's a while since I read him.  Roughly speaking:
Value Demand: Things that you want an organisation to do for you e.g. Change a tyre on your car
Failure Demand: Things that go wrong in the process of trying to deliver the value demand, that in themselves need fixing.  e.g. Breaking the hub cap while changing the tyre, which then requires a separate extra task, and extra cost of a new hub cap.

However, for an IT project, I don't think this is enough of a distinction.   Seddon seems to be writing mainly about service organisations, where what's required to respond to a particular service call is understood. I would say that in software development, things can a little more  complicated.  In software development at each stage of the process, extra value demand can be discovered.  I don't know what anybody else has called it, but I'm calling it discovered demand.

Some examples of discovered demand?  OK, here goes:
Discovered Technical Demand: A tweak to a web page design (Value Demand) results in a huge number of extra sales of widgets. This brings down the sales database and makes the entire site unresponsive. An entire new database architecture is required to deal with this.  This is what my old boss Mik Lamming used to call "a success disaster."
Discovered Value Demand: Now it's got really easy to buy widgets on your site.  It seems obvious that at the joyful moment when you buy your widget you should also be able to comment on your widget purchase on all social networking sites.
Discovered Value Demand: Now the process of buying widgets has been streamlined, it's obvious that some information that's asked for across several different pages would be better off being asked all at once.

Some examples of failure demand?
Failure Demand: The ways the CSS is set up means that most of the importand credit card fields can't be seen on a standard 800x600 laptop screen.
Failure Demand: It at any point you press the "back button" you get a 500 error.

Once you start to think about this, you start to realise that for digital project management, this might be one of the answers for the "ultimate question" of Taiichi Ohno: "What is it?".

What Digitial Project Management is about is delivering value.  A lot of value is discovered in the progress of a digital project. So, for most projects:

OK, back to my diagram.  The point that I'm trying to make with it is that at every stage of development value is discovered and failure demand rears its ugly head and needs to be attended to.  This might explain why the average error on the estimate of effort and/or time taken to deliver digital projects is 150%.

This is a test.