“Who are we kidding? Apps are built to earn money. They are a product created to generate profit, and there are a number of ways we can get them to do just that. The simplest, and therefore most common method is …”
So says a typical email in my inbox. But. It ain’t true. Apps are also built because people love to build things. Many, many apps – and websites; and Real Stuff; — are built because people love to built things, and if they didn’t have to earn a living they’d still be building things. For some people, earning money is the pesky thing getting in the way of building the apps they’d love to build.
I was recently fortunate enough to catch Max de Vries on a trip to the UK. Max has overseen complex IT projects in Europe, Asia and the US, in finance, public sector and now games for over 20 years, most recently being in charge of Popcap’s Plants vs Zombies franchise, overseeing the launch of PvZ 2 and PvZ-Garden Warfare. I managed to fire off two quick questions before he had to go:
- Q: What are the top 3 things every project manager should know?
- Who to trust; how to communicate; and what would success look like.
- Q: What are the common mistake that inexperienced project managers make?
- Not realizing they are inexperienced
- Making estimation a political process
- Miscalculating the cost of saying no vs the cost of failure
- Not thinking about the critical path hard enough
- Thinking that people know what they want
- Underestimating the value of a high functioning team
- With agile processes: Modifying a process without understanding the reasons why the process works and doesn’t work
So now you know.
Had enough of arguing about agile? Concerned that software development has been side-tracked by religious war? Keen to inject an element of pragmatism, not to mention fact-based-ness into the debates? Perhaps what you need is a New Deal at http://www.the-new-deal.org
I found about 10 years ago that everything I delivered in software took me three times longer than I expected.
Eventually I realised that my ‘gut feel’ for estimating a coding task was ‘about how long will it take me to code this if I make no errors & get it right first go’. Which is a good starting point for an estimate, so long as you then go on to add testing, debugging, changing or misunderstanding requirements and time to release. So if you have stable requirements and a pushbutton deployment toolchain, then x3 is about right. If you haven’t, x5 is probably closer.
I note that others have found something similar. I’m please to find that multiplying by 3 puts me about 4.7% ahead of the curve – http://alistair.cockburn.us/The+magic+of+pi+for+project+managers.
Somehow earlier this year I subscribed to the chaos report email. Given the significant criticism of chaos report’s measure of success – on time, on spec, on budget – I was amused by this week’s email which poses the question whether their success criteria are relevant. What the Standish group does have that most of us don’t, is access to a large number of (unpublished and hence unverifiable) examples.
From the email: “Which is more important project success or project value? It turns out the project success and project value is orthogonal or at right angles to each other. The harder you strive for perfect success the lower your project value. The harder you strive for greater values the lower the success rate.
We know this because we have coded each of the 50,000 projects within the CHAOS Database a success rate and value rate. Each rate has a score from 0 to 100. By grouping the projects by organization we can come up with a ranking by success and value. We then can compare the rankings. One of the items we discuss is another question Is the traditional triple Constraints (cost, time, and quality) measurement still appropriate?”
I’m surprised by the assertion that success and value are orthogonal. I’d have thought that there was at least some connection between time/cost/functionality and perceived value; if the value of your project is not in the spec, surely you wrote the wrong spec?