The Project Management Monkey

The App Store review process and queue theory

2011-11-02T11:49:00.008+01:00

The last weeks I have had the mixed pleasure of pushing 19 apps through the App Store approval process for a client. Some updated to improve iOS5 compatibility and some brand new. It might be bizarre that this gave me associations to queue theory, but it did and I will explain why.

I won't claim that I remember much details from the queue theory I had at NTNU exactly a decade ago, in the context of building scalable web apps, but I remember this: If you have a mixture of a few large jobs and a lot of small jobs, you can improve the throughput a lot by introducing two queues[1] - one for the small jobs and one for the large. That way the small jobs can flow through quickly, while the big beasts naturally take some more time, but that is hardly unexpected.

An extension of this principle is exactly what Apple should do. I find it slightly ridiculous that an unchanged app (apart from the fact that it does no longer crash on startup with the combination of iPad1 and iOS5!) can take a week to review, going from version 1.1 to 1.2... So, Apple: Get that high pri queue for small jobs (i.e. minor bugfixes etc.) going and the perceived throughput from the job's (app submitter's) point of view will increase greatly! In practical terms, get dedicated teams (or time) to review updates of existing apps and make them flow through the review process on a less than two day average, compared to taking maybe the bulk part of a week today.

[1] - Or a variant thereof with allocating slices, as in a time sharing system like in modern computers - which de-facto will make small jobs flow through quickly if each job gets an equal amount of time "each round" and the big is not served again before every small job gets its share.

Adobe acquiring PhoneGap - for better or worse...

2011-10-06T21:02:00.006+02:00

I just wanted to write a really short note on the news two days ago that Adobe is acquiring Nitobi, the makers of PhoneGap.

I have been using and talking PhoneGap for about a year and a half now, building a rather powerful authoring tool that uses PhoneGap with some native extensions to build apps for iOS and Android.

Anyway, I am thrilled with the prospect of one of the industry giants, with excellent track record on the tool side, supporting PhoneGap. I also feel this gives a certain approval of PhoneGap as a serious tool. On a related note, I have had clients that I held presentations for about cross platform mobile development in 2010 come back the last months and say "we were wrong, there is actually a use for PhoneGap". Since it is hard to plot a graph safely from a random subjective data point or two, having Adobe "stamp the whole chart right there" - saying there is room for this technology for sure, was really a energy boost for me.

On the other hand, I am slightly skeptical based on Adobe's (lacking) track record on mobile devices. As I have noted before, I feel that the really great mobile platform from Adobe has been only months away since I tested an early Flash Lite edition in 2002. I am also not sure if I view the split with the ASF taking care of the OSS version as a good one. Does this mean there will be a split of versions and functionality also in the core product and APIs? For me, that would be a huge disappointment (while I find it perfectly fine that the PhoneGap Build service will be developed as a closed proprietary Adobe product and of course that tools like Dreamweaver and Photoshop gets export wizards and whatnot!). And damn, PhoneGap is a better name than Callback. :-)

In any case it is exciting times for mobile apps development in the space, literally, between HTML5 and native apps.

And on a day like this I cannot end without (even though I am not generally a fan of throwing around either "R.I.P." or "awesome" all the time): R.I.P. Steve Jobs, AWESOME innovation legacy you leave behind - and you changed a generation's view of product development and importance of design in innovation.

WeVideo Champagne Supernova

2011-09-19T23:42:00.009+02:00

Yeah, we[1] have launched WeVideo! The US team even won a prize for their presentation at Demo 2011. Congratulations! I must I admit I am sometimes that boring realistic and analytical engineer - how refreshing then to have someone else to bluntly say "we will revolutionize social video editing".

We have been thinking hard around pricing, technical architecture and countless details before the launch. I might write something on that later. But now, a more practical test. People often say "eat your own dogfood" or, as I will insist on phrasing it in this case, "drink your own champagne". Anyway - use your own tools if you believe others should.

I've gone ahead and done just that. I just drove from New Orleans to NYC for my August holiday and now I created a short summary of the trip. I am a total amateur, like most of our users will be, so you will maybe not be that impressed by the resulting video itself. But I was, honestly, impressed by the tool when using it for real, not just testing some boundrary case for technical reasons.

For this 3 minute movie, it was uploaded videos and photos from 2 cameras (one mid-range SLR, the Nikon D90 and one Nikon point and shoot from 2007) and 2 iPhones, put it together in a timeline and slotted in some mp3s[2] - then uploaded a screenshot of a google map and added some transitions and texts in the tool to end up with this video:

What struck me was that after getting the raw material into the tool, the rest was really easy. Imagine how disruptive this can possibly be as bandwidth continues to grow exponentially...

The launch seems to have gone well technically so far and it has gotten nice reviews. Of course the sign-up rate (4 digit number of sign-ups in the first few days) is not quite up where we had dreamed. On the other hand if it keeps groving at a steady rate we will have the whole world as users by Christmas. :-)

Now go on to WeVideo.com and invite some friends to edit video collaboratively - good luck! And drop me or the WeVideo team a note if you have a suggestion or find a bug - we are now in what we have defined as a public beta version and need all input we can get to get this right.

[1] - Full disclosure: I am a member of the board at Inspera, that holds a majority ownership position in Creaza AS and (directly and indirectly through Creaza AS) controls 52% of WeVideo Inc. I have also played a relatively modest role in the more practical matters of making everything you don't see (clusters of web servers, rendering farms and the like) work and scale, as a consultant.

[2] - Forgiveness, not permission. Pretty-please. The album Fuzzy by Grant Lee Buffalo is one of my all time favorites. If you do not own it in at least two formats already, go ahead and buy it in the iTunes store (or your favorite equivalent) right away!

Make the desire to win bigger than the fear of losing

2011-08-04T06:31:00.002+02:00

I was recently made aware of some research about penalties in football (soccer, for any US readers). How can this be relevant in project management? Maybe it is a stretch, but I think it can learn us a thing about motivation. Let's see.

I cannot find the original Norwegian source now, but the basic content was this: When the last penalty is taken in a football penalty shootout, the likelihood of scoring is almost twice[1] if your team will win if you score than if your team will lose if you miss[2].

Even though generalizations from non-related fields is risky and I am a fan of brutal honesty[3], I will take my chance on this one: This can learn us to make the desire to win bigger than the fear of losing. If your project team feels scoring that goal (be it completing their component, polishing that presentation, or something else) will win the game, it is better than if they fear their mistake will drag the entire project to a failure.

So making each team member feel that their contribution is essential, but creating an environment where everyone is sure someone else will pick up the ball (!) if he fails his current task, sounds like the winning formula. Maybe not rocket science (it is football science, after all!), but a good reminder?

Now go on and win your game.

[1] - Again I didn't manage to find the original numbers, but they were something like 40 % and 70 % likelihood of scoring. Will update this blogpost if someone pings me with a link to data or original article. The source is as credible as it gets in Norwegian mass media, at least (A-magasinet from Aftenposten) - and it seemed to reference valid research.

[2] - I.e. the statistics were for the tenth penalty, and equal score before the penalty will give the first situation and the team not having the shooter being one goal up would be the second.

[3] - For the record I am also a fan of a lot of praise. But being direct about the negative also gives credibility to the praise. Maybe a separate blog post on this later!

2011 - The Summer of, eh, Work?

2011-06-12T15:41:00.003+02:00

A year ago I wrote about our preview of the online social video editing software Creaza. Even though the social video editing service for consumers is still in closed beta, we have had two fun milestones lately:

A two page article in Norway's largest business newspaper (DN), focusing on the big plans/hopes, the software itself and launch of the US company, Creaza Inc.
Creaza was one of three startups that won the judges attention at a Plug and Play Expo in Silicon Valley recently, as Techcrunch noted

This could mean that we need even more scaling capabilities (we currently have user numbers in the hundreds of thousands on the educational version, a different ball game than if we get millions of active users) sooner rather than later.

That, and for me personally two-three other projects in an intense phase for other customers, could easily mean extra work this summer. Anyway, I just booked plane tickets for doing a late August road trip from New Orleans to NYC and I am also going to visit the Sziget Festival in Budapest, so no complaining! But I think we are in for an interesting summer of work and fun before that...

Full disclosure: I am a member of the board at Inspera, that holds a majority ownership position in Creaza AS and (directly and indirectly through Creaza AS) controls 52% of Creaza Inc.

Small Scale Globalization as a Practical Reality

2011-05-17T09:07:00.004+02:00

The last two years, I have been teaching e-business at a college. When covering internationalization, I am talking about global supply chains and big outsourcing providers. We are probably all getting used to designs, components and finished products travelling across continents (to be fair very often produced in China based on a design from the US), before ending up in your lap(top). I had not really thought that much about how this links to my more down to earth business and software development projects.

The fact is, to me at least, doing business globally has become more practical and accessible to small firms. The Internet has changed how we work and collaborate and I will provide some facts about the work on a service we are launching in full scale soon, as a practical sample:

- I have been using an Indian firm, PixelCrayons, to implement the web page design - with excellent value for money and professional project management exceeding my expectations

- My partner in Romania, Exswap, has been doing excellent work as usual and collaboration from day-to-day is done a lot through Skype (acquired yesterday[1] by a not unknown software giant from Redmond) and other online tools

- My excellent hosting provider is based in Germany

- The core issue tracking and development hub, at heart is Jira, is delivered by Aussie company Atlassian (at first via their brilliant start-up scheme which gives you the software for free and the little you pay goes to charity), we use open source tools developed using what a more buzzword-compliant post would call crowdsourcing, and we build our product on top of many of Google's tools and services that live in the cloud

- I both learn from and contribute to groups/email lists that are truly global in nature

- When we actually want to meet in person, the competition in the airline industry has made the prices reach a level where it is not a total showstopper, even for small firms. To me, this "democratization of air travel" is a part of the same picture.

- And, a bit on side, maybe -- even on this very low traffic blog I have received comments from all over the world (US midwest, California and eastern Europe) on email

All of this might be small things that we take a bit for granted from day to day, but added together it is in fact changing radically how we recruit, manage, purchase and work - in the broadest sense of the word work.

To a certain degree the vision about a rich toolset in the cloud, using a best of breed strategy, is already a reality. It makes trial and failure less expensive for new entrepreneurs, and I believe it fuels the speed of innovation. Exciting[2] times.

[1] - As you can see, the final version of this post had a little time hanging around as well, since "yesterday" is "last week" when clicking "Publish" - but trust me, it is nothing compared to the time from rough bullets and the idea to the (semi-)finished post. :)

[2] - Caught up with the latest editions of Economist on the plane down to follow up with my partner and it seems the times, at least in and near Silicon Valley, is so exciting that even the more established analysts see it as a bubble (bubble warnings from the blogosphere have been here for a few years, from when Groupon was just a random small company)...

Pricing strategy: What is your next-to-nothing threshold?

2011-02-23T08:59:00.000+01:00

A while ago (a long while, in fact - this post has been in draft state for forever), when travelling, my harddisk broke down. I had thought until then that my ad-hoc backup regime was sufficient. Not quite so. It was a combination of three things (in addition to the, too dated, ad-hoc backups) that more or less saved me: Subversion, web based email and Dropbox. My Dropbox account was a free one, but as you can imagine - I have now upgraded to a paid plan to have more space (I am really a fan of the service, by the way!).

But this post was not intended to be about backups, rather about pricing. The hours (and potential data) lost in the above transformed me from a enthusiastic evaluator[1] to a paying user of Dropbox. Their price point of 10 dollars per month was just above my next-to-nothing threshold before, but after this near (data) death experience, 10 bucks suddenly seemed like nothing.

Micro payment (when I say micro, I mean micro - think 1-10 cents for a one time access to some content) was for a while a sort of holy grail for many in the online business. I think the hope for this type of payment patterns might be waining, but a new "next-to-nothing" paradigm has certainly emerged in app stores, such as Apple's or the Android Market for mobile devices.

Also subscription based services of various sorts seem to manage to convert at least a small portion of its registered users into actual customers (in my world he is not a customer until he pays for the service!). Other examples of small payments include donations (Wikileaks, anyone?) through PayPal and others. Personally I have donated to a couple of open source projects, for instance the pdf generation program I use for all my invoicing etc. in my firm. I do not have hard facts, but I think these schemes are on the rise as well - and payments are often quite small, so I will include them in the next-to-nothing bag of pricing schemes.

Some, grumpy theorists in particular, may claim that the next-to-nothing threshold is just a special case of perceived value vs. price. That could be, but it is still an interesting one. I also think that in general, the next-to-nothing-limit can be very close to nothing for personal use, but often a bit higher for a service aimed at professional users. This is a particular challenge for the pricing structure for the launch of an exciting B2C service I am a bit involved with this spring - probably another post on that later.

One last thing: The power of really paying nothing should not be underestimated. Even if your next-to-nothing offering looks very compelling on its own, that could change very rapidly as soon as someone (such as Google, as a not quite randomly selected example) offers the same service for free...

[1] - If you haven't tried it, please do - it is purely great to have access to what you know is the latest version of the file both on iPad, phones, PCs and Macs -- as well as from a web based interface.

Norway - the land of opportunity?

2010-11-16T17:14:00.004+01:00

When travelling this weekend I did some catchup in the pile of unread magazines and found this graph in The Economist:

It shows the relative income differences from one generation to the next (US=1). And it turns out Norway scores very well on this metric, so maybe state funding of educational loans and a pretty egalitarian society pays off in the end. The income mobility is almost 3 times that in the US and the UK.

Interestingly enough, the UK scores just as well as the US. I guess it is just prejudice, but I have always thought of the US as the classical meritocracy - if you are good, you can succeed no matter your background - while my oversimplification of the UK society is as more of a gentlemen's club where the right school, connections and parents are all a necessity to do well.

So the American Dream might just as well happen in Norway, today? I guess still lawyers breed lawyers more often than others, but on a macro level it does not look too bad. Anyway, I think it is a graph to be proud of (still a pity to be beaten by the Danes again, of course).

Vintage Code on a New Canvas

2010-10-05T19:46:00.006+02:00

I wanted to do a small experiment with the HTML5 Canvas. To do it, I found some Java code I wrote in 2001[1] and ported it to gwt-canvas (thus compiling a Java subset to JavaScript). It uses a naive redrawing technique[2], but the point of this test was not to optimize performance or create production quality code[3].

Anyway, you can see the result here: CanvasPairs (external link). Try it and see how fast you can find all the pairs!

I did this and a few other, more graphically intensive, experiments to test canvas performance on a few devices (iPad, iPhone and Android-based phones mostly) and feasibilty for doing casual games or minigames inside edutainment titles using technology such as PhoneGap with the HTML5 canvas. The results were somewhat mixed, but for the iPad I have high hopes that IOS4 will improve performance in the Safari browser and on even the not-so-new 1.5 version of Android on a medium spec'ed phone, it was relatively impressive.

My feelings about the technology is ambivalent. On one hand I am excited about what will soon be possible to achieve in all browsers without plugins, but on the other hand the maturity feels a bit like Java applets in 1998 or Flash in 2003. At least I am sure progress will be much faster this time around.

[1] - This summer I visited Moet&Chandon and IIRC, 2001 and 2003 where the last years of vintage produced. I won't go as far as saying no good code has been written since 2003 :-), but the reunion with the code from 2001 was not that bad.

Rewriting it in GWT proved to be a little more work than I thought at first, but I am always (too) optimistic... The rewrite included just skipping a few parts (highscore lists, double buffering, keyboard input for pausing etc.) for now and reimplementing others (for instance a basic preloader to replace the ImageObserver and a string drawer based on drawing segments of an image of symbols, since text on canvas seems to be a bit shaky at the time of writing).

[2] - Basically it redraws the whole canvas for each and every frame. While this (minus some background caching, maybe) might be needed for more advanced games, this particular one might have gotten away with a bit of Image or DIV flipping, I guess - but that was not an option for the platform which it was originally developed in 2001.

[3] - One might also argue that the simplicity of the sample would have made it possible to do it without any canvas (HTML, Flash or Applet based) at all. Again, that might be true - but the main point here was not to implement the specific functionality of the game itself.

Getting beyond the first sale for a micro ISV

2010-08-28T15:06:00.007+02:00

...or: putting a long time failed goal public.

In 1999, about the time I was ending my first year in college, I had created a few very simple Java-based games and established my first company. I discussed with my girlfriend (now wife) who was skeptical about paying for a domain/web site, but we (?) decided to do it. Then, with a strike of luck, the largest telecommunications company in Norway - Telenor - found and liked the games and wanted them and similar games for their ISDN-touch screen platform. In total I created 7 games. The payment wouldn't impress anyone (certainly not me) too much today, but as a student it was definitely significant and I also managed to do the deal on a yearly subscription basis rather than as a single payment.

Getting that big customer will probably be classified as luck. The problem is that a micro ISV[1] cannot rely only on pure luck in the long term. Thus the key question becomes: How can you increase the chances of being lucky? And more specifically, how can you get beyond that first project sale?

In my experience recurring revenues are often calculated when pricing a complex software projects (ever heard the "but the next similar project will be much more profitable", only to find that the next project was not that similar in the end?). To talk about “productization” is easy, to successfully do it is not.

I will argue that you can increase the chances of being lucky by (1) securing your rights to the product, (2) thinking about it like a product, (3) building it as a real product and finally by (4) doing the marketing for the product - often only with the guerilla methods available to small firms.

I will go through each of these four points in order and I will use a system I made the first version of in 2003 as a working example. This system is a web-based recruitment system currently used by a single recruitment agency. I will try to see where I did wrong, comments regarding the specific project is inline in italic, and hopefully get some of it right in the aftermath of this blog post. Since I have NOT been successful in trying to sell this to customers beyond the first one, you are now watching live the first structured attempt at changing this (and could argue who am I to write this blog post[2]…).

By putting the failure public, will I finally manage to do it? Anyway, on to the four components I will go through, starting with the intellectual property rights (IPR).

Secure your rights

This might be basic, but if you plan to reuse the software from a project either in other projects or even in a product you must get the IPR correct from day 1. In my experience this is usually possible, but may vary according to type of customer.

On this point I was not too bad, I was sure to get full IPR (giving a partner pricing scheme to also get full IPR to changes developed over the years), but I had to give my customer exclusivity in Norway. In retrospect, a few enquiries have come over the years from Norwegian firms wanting to license the system - so negotiating away that clause at the outset might have paid off. My customer, although always constructive, did not want to give up local exclusivity the one time a customer that was ready to buy actually emerged.

Think about it like a product

Next, I strongly believe you have to think about your product as exactly that – a well defined product. It is easy enough to say that the core of some project is a “product”. But what is the product exactly? Be specific - thinking about exactly which user interfaces and functionalities are part of the product forces the thought process around the product.

Likewise, be specific about who is going to buy the product and what is their willingness to pay? What is important to the customer might be different from what you assume. One way of finding out is getting partly founding for new features from early adopters. This forces your pilot customers to put their money where their mouth is.

Think about the most likely competitors. If there are none you can either hope to be a true genius, but it might also indicate lack of market. Don't let a number of competitors scare you away, a micro ISV can be nimble and develop in new directions quicker than they can! Often it is great to be small and not have a lot of legacy code and customers that use it to think about.

On this point, I just have to say Mea Culpa. It was more a vague hope than a clear strategy behind the product thinking. A few years later it seems to clear to me this is not a volume product (also given what we can support) and it will be priced between the simplest competitors and the offerings from huge ERP/HR vendors.

I have tried to think more about it like a product lately, will return to that when I cover marketing, but first on to building the product.

Build it as a real product

It is not enough to think and talk about it like a product, if you are going to support it without too much grey hair and get the scale effects, you also have to build it like a product. This has practical consequences all the way down to the details of the technical architecture and the underlying data models.

Regarding user interfaces there is also a need to be clear on what is part of the product and what is customer specific – and find a clear cut way to manage that. If you throw hard coded texts or data fields specific to the first customer around the user interface, it is not a product. Also, if you have to fix the same error for all customers, it can be an indicator of a flawed architecture or structure.

In most cases you won't have partners selling your product from day 1, thus you need to think about supporting (and possibly hosting) the product professionally. Then it matters a lot that it is built in a way that grows maintenance work in a sub-linear way with the number of customers[3].

Again, on this point I did not do to well at the first attempt. When trying to generalize this now in 2010 for the new version, some rework had to be done to make possible installation for the next customer smoother. I also made what I think was a smart move by trying to provide easy hosting, or letting the customer forget about hosting all together, through possible single sign-on with their existing solutions. I also made connecting to enterprise systems easier by exploring a module that will run PHP (in which the original system was built) inside the Java application server Resin, called Quercus.

Marketing for the product

Many entrepreneurs seem to almost lose interest in a product once it is approaching something that looks (remotely!) like production quality. Then it is on to the next project, although they might claim they are both "products". Well, it might be fun (I think so!), but if doing so one should be honest enough to simply call them projects, not fool oneself by calling them products. That being said, it is nothing wrong with trying out several product ideas – if you can make even one of them fly, to me that is just plain fantastic – but remember that not all projects need to become products.

A product should have a name. Try to find a good one. Create some, if very simple, marketing material and try to get it spread. These days many channels are available, but it is still much easier said than done to create the amount of buzz needed to reach just those potential customers.

If you really believe in the product and it has a great potential, here is the area you are most likely to need professional outside help. It can be from partners or external investors (VCs). Marketing and internationalization can be frightening expensive and for a software company founder to be excellent at it is probably the exception rather than the rule.

If your product is consumer oriented, the Freemium model has gotten quite a bit of attention lately (some would say too much, it is certainly not a one-size-fits-all silver bullet). Andreas Göldi covered some properties on when the Freemium model can be successful in a blog post in 2009, it comes highly recommended. If the free version is great, maybe the word of mouth can help your marketing? In addition to pure guerilla tactics including wise use of social media[4], some forms of targeted advertising might be feasible. Very targeted search word advertising and doing talks and/or stands at conferences or conventions might be worth exploring. I am not the best example of this (again, look at the 7 years of a great system still with that single customer!), so I am sure you can come up with more creative ways of doing this than I can!

How did I do on this point? I simply didn't. But I have settled for a name in the process of upgrading the solution this year. RightCruit.com is going to be the proud new name of the product. And I have now written this blog post (and not least done the analytical work both leading up to it and starting doing the operational work coming out of it). I have to admit that my blog with very limited traffic is not ideal, but it is a starting point.

In addition, and more important, I have good ambassadors in my customers that have used the system since 2003. I still think the most likely way of doing a sale is through them and their international contacts.

So by posting this I have made public the goal of making the first international sale for RightCruit. If it happens, have no doubt there will be a follow up post or comment on this page. In the short term, I will use the comments field here to give a quick update as I progress in trying to make it right using my own medicine. The next month or so, I intended to record a small presentation video and maybe buy some Adwords ads for those to see if that can generate any qualified leads.

I welcome comments, both on the theoretical argument and on what I am still doing terribly wrong with my practical attempt at selling RightCruit to new customers. At least can't be the name? ;-) I thought it was utterly clever with a word play on “recruit” and good meaning to it as well...

[1] - ISV = Independent Software Vendor. When using the term "micro ISV" I generally mean companies with only a handful of employees, for most of the time in the specific example it was actually less than one FTE. But some of the argument above is valid also for somewhat larger companies struggling with the tension between customer projects and product development.

[2] - If I were to argue back I could mention that I have been involved in some successes as well :-)

[3] - This might sound easy. It is not. I have seen examples of the time spent being almost exponential and when having the first small handful of customers, the coordination and attempt to do projects for customers along with product development almost stalled progress completely for a while.

[4] – I don’t claim to be the biggest expert on social media usage. I do have opinions, however. Without attempting to lay out rules and certainly not a social media strategy here, I would say that adding some value to a discussion or offering something of value (I hope this blog over time shows some of how I think) is always a good idea. And always, always, always be honest about who you are and who you represent.

Also, thinking about real life parallels can be useful (in a party, would you go “hey, this guy that none of you know just said that something I wrote was great and I will repeat that without any other comment to all of you”?), even if it is not always straightforward to find a relevant analogy.

Internet as an application platform - even for HD movie editing?

2010-06-11T08:32:00.008+02:00

I have read a lot and also written a bit about web based applications of different sorts and how business models in the software industry are changing. The move to Internet-based applications has been promised for maybe too long, but from my point of view it seems to be going more mainstream lately - which for instance a front page of the Economist in October 2009 indicated.

In addition to moving more mainstream in terms of users, I think web based applications are wideing the scope also in terms of types of applications that move online. The last weeks and months I have been lucky enough to be involved in a project taking this somewhat to the extreme - trying to do HD video editing online in the browser.

With the launch of Flash Player 10.1, Adobe brings hardware accelerated mp4 support to browsers on several operating systems - and based on technology from the Creaza movie editor a preview of a upcoming version of online video editing with HD video support has been made in record time by a dedicated team of developers in Norway and Romania. You can do a test drive yourself, by getting the new flash plugin and following this link to the online video editing application preview. Make sure to use the commenting function to tell us what you think.

The technology preview version does not have a save or export functionality, but you can render the movies live and watch them to test the quality. In the screenshot below I am changing a text about 10 seconds into the example movie. You can also add transitions and effects, and to be honest I was amazed how the results look. You can have multiple layers of effects, sound and video (including multiple videos playing in different parts at the same time) and it all renders on-the-fly.

Full disclosure: I am a member of the board at Inspera, who owns a majority stake in Creaza AS and has the IPR to much of the technology used in the preview application.

Fast mobile and fun TV...

2010-05-21T08:55:00.005+02:00

...some even quicker observations on keynote of Google IO day 2.

In short, the new and faster version of Google´s OS for mobile devices, Android version 2.2 codenamed Froyo, was launched as expected. There was some picking at Apple with references to their famous "1984" superbowl commercial calling their approach Draconian, push APIs were launched "not to address basic shortcomings in the operating system of the device, such as lack of multitasking", demonstrating tethering in Android with the words "now let´s turn to a device that doesn´t have connectivity, how about that iPad?", etc.

The Android momentum is high, with 100 000 activations per day. The Flash plugin (10.1 public beta) was announced as expected. I am looking forward to see how it performs, as pointed out yesterday Flash on the mobile has yet to deliver (when I supervised a MSc-student in 2005 doing context-based mobile app that it was supposed to be half year away from being great, which I think it has been since...). Hopefully this will be it!

Google TV was also launched, not quite as pre-announced as the Android Froyo, but not unexpected either. Personally I am more interested in "Chrome OS for TV" - to have a lightweight connected OS with browser (for public screens etc.) in TVs than the PVRish and EPG aspects that it was focused on in the announcement, but I guess it can be used for both.

It will be interesting to see if Google will be the ones to get voice control right. It has been tried (several times) before, including getting similar wow-demo-effects to the ones we saw in the keynote working. With all the data to improve their algorithms, they might just be.

Oh and to leave you with a maybe non-exciting note that I forgot yesterday: App Engine are getting SLAs and standard SQL databases, which might in fact be of the more important announcements for CIOs considering running apps in Google´s cloud.

Quick reflections on today's Google IO keynote announcements

2010-05-20T00:30:00.005+02:00

In today's keynote at the Google IO conference, a pretty impressive list of announcements was made official. [And tomorrow everyone is keen to see news about Android, I guess?] I want to quickly comment on two or three that I find particularly interesting.

Web video: Opensourcing the VP8 video codec

This was expected to happen at some point, after Google acquired On2. The list of companies supporting the new format is interesting and Microsoft has seemed to confirm that IE9 will support it.

This might put H264 on death row as a candidate for the video format for web and if adoption goes as Google hopes, it will pose Apple with an interesting dilemma. This will indeed be the case if the flash player will be among the first environments to deliver a good user experience for WebM. [Another sidenote: Again, it will be interesting to see tomorrow if Flash on Android is finally approaching what Macromedia and later Adobe has been preaching about Flash Mobile for more than five years... If it is, Apple might get push from their user base, me included, to get access to cool apps on their iPhones and iPads.]

Web applications part 1: VMware teams up with Google trying to deliver "the cloud OS"

Tim O'Reilly wrote a great post on the development and State of the Internet Operating System a few weeks ago. VMware secured a deal with Salesforce recently to allow developers use their Spring platform there. Today it was announced that it will also be readily available on Google App Engine and also integrates more easily with the Google web toolkit.

VMware's Paul Maritz was even quite explicit about the goal, saying something along the lines of: "If the cloud is the new hardware, you can see this as the operating system." That could mean easier cloud-to-cloud (private or public) interoperability for both ISVs and companies, which can only be good. Of course, there are other main players in this space. One should not underestimate good old Microsoft - they certainly have some experience building successful platforms that third party developers deliver applications for...

Web applications part 2: Browser capabilities and a new webapp store

There was also a few cool demos of what can be done in plain browser based applications without plugins today (so called HTML5). The rapid development in this area of course also accelerates the movement of applications to the cloud. As far as I noticed, there weren't any specifics on Chrome OS [Tomorrow morning?], but it makes more and more sense to have a OS totally focused on web for every day that passes.

It remains to be seen if the Chrome application store will be a success, but it must probably be viewed in the scope of the Chrome OS to be judged fairly. It might give an option for independent developers and small companies to monetize on their products, much like Apple has championed for mobile apps.

It is very interesting times. In my company, I am doing product development in the mobile/augmented reality space and I am amazed with all the libraries, frameworks and options available to a startup these days - it is a huge difference from only a decade ago. Google is in my opinion one of the companies that seems to get the balance between open and proprietary innovation quite right, so kudos to them for helping to drive this exciting progress.

Startup idea generator

2010-05-08T22:37:00.004+02:00

I stumbled across the startup idea generator today. It tweets a brilliant (?) new business idea every five seconds or so. Very much buzzword compliant. Content asymptotic towards zero, but that is not always a problem, is it? Idea 1 025 431 (yep, over a million and counting) was for instance "Enable Twitter-connected technologies to solve the problem of crowdsourced communities".

Come to think of it, some of my e-business students will probably argue that the lingo of business is just like this... I'll share one piece of anonymous feedback from their survey:

Worst thing about the subject: That we have to have it!
Best thing about the subject: That we are done with it!

Oh, I like the joy of teaching! :-) Seriously, I think I do - and for the record: There were some encouraging pieces of feedback in there as well.

Old, grumpy and agile – the ideal combination?

2010-03-23T21:44:00.009+01:00

This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?

Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?

I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version[1]. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.

It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.

My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days"[2] (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").

[1] - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.

But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.

[2] - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.

Portfolio planning: Create storms, not forms

2010-01-08T10:30:00.007+01:00

I said some time ago that strategic portfolio management goes beyond what is typically achieved in a project management office (in my 8th "brief tip" for project management). My best attempt at formulating this in a rememberable way comes here: Create storms, rather than forms.

I think better value from a project portfolio can come from creating storms - honest discussions between people that typically own the day-to-day business operations that the projects are about to change - than using very detailed sign off procedures and authorizations. Rather than requiring many people to sign off projects of a certain size, have them take part in the regular meeting that is the only place such projects can be authorized for initiation.

An important outcome of such meetings is which projects not to run and also to create visibility of the most important projects for senior management. Ask top management: "What are your current major running projects and which are the top priority ones?" Getting any kind of stuttering as a response is a big red warning light.

If you just take the form-based "PMO coordination" approach, there is a danger that all projects will just be administred - not prioritized. One useful way of visualizing projects can be as a radar, with distance showing the expected end date and the size of the dots showing the size of the project, possibly with sectors for business units. Over time, some rules of thumbs might evolve about how many major project the organization is able to digest, which types of projects require the most coordination across business units, etc.

A weak point of the method of de-facto giving the line management power to decide which projects to run, is that often only the needs of current customers will be heard. This is similar to Christensen's Innovators Dilemma. You may make your self obsolete through many incremental innovations of the status quo, that by them self make sense - but fail to capture big shifts. This is really a separate discussion, but one solution might be to separate early stage R&D projects both organizationally and from the project prioritization process.

A final word, maybe to avoid any unintended storms (!): Forms can also be useful. The most obvious example I can think of is that a suitable template, or form if you will, can contribute to getting the project owner to think in business case terms when arguing why it is a good idea to run just their project... And PMOs can of course be useful facilitators for the decision process. Also, I am not suggesting to get rid of documentation or preparation for the meetings, but I still think that the main point is valid: Prefer storms over forms, decisions over documentation, and prioritization over administration.

Those who can, do...

2009-12-13T21:18:00.004+01:00

You have probably heard some variation over the saying: Those who can, do. Those who can't, teach. Those who can't teach, consult. I am actually going to complement my consulting by teaching the next semester, so I guess that puts me quite clearly in the "can't do quadrant"? :-)

Anyway: The subject I am going to teach is a 2nd year college course in computer science, focusing on XML and web technologies, at NITH in Oslo. The gig will be starting in January.

It might have been only a matter of time before I had to try this[1], with parents that are both teachers... Even so, it is only a thing I do a small portion of my time because I hope it will be energizing and meaningful. Or maybe it'll just be frustrating and make me feel old? I might post some of my experiences after the semester.

With the holiday season coming up I would also like to take the opportunity to wish you the best and suggest you make sure to really recharge those batteries that might be close to running out as everything must be finished in time for Christmas...

[1] - One might argue that I have tried a little bit already, as guest lecturing and training short courses is something I have done on the side both while I was a student myself and later.

Summarizing my brief tips for project managers

2009-11-03T19:26:00.004+01:00

So, that was the 10 posts. Here are my 10 brief tips for successful project management summarized (each sentence links back to the individual post):

When I look at it now, what do I feel – should I have changed something drastically? I think I might have created one specific post on goals. I think it is really important to have the goals clearly defined (and on the right level) and understood across project team and stakeholders. That is maybe buried a bit in the “managing expectations” heading in the current list of tips. Make sure to have it clearly visible in your mental checklist.

Apart from that and to be sure to communicate roles and responsibilities very clearly (and also to always work in stages or increments, but that is sort of given and an underlying assumption in everything that I have written so far, I think...) I am quite happy with the list as it has developed. But you might not be, and then the best way to show it would be leaving a comment. :-)

The always challenging question of summarizing it all in a sentence? Well, how about: Be proactive and care for your team, choose common sense rather than legal fights and have fun!?

Final brief tip, #10: Look beyond the project

2009-11-02T20:03:00.001+01:00

I must admit that I love projects. I find them energizing and really enjoy going from the unavoidable feeling of uncertainty if it is feasible at all, to a successful delivery. I also like to be able to finish off, and then start a new one – with clean sheets (for the joy of Norwegian readers, I’d like to add a reference to Alf Prøysen, who came from a place close to my mother’s, at this point: “Du skal få en dag i mårå”, which I would say translates more or less to “You’ll have another chance tomorrow”).

Even if it you are like me and are happy about finishing off the project and then start a new one, possibly a different place and in a different field: I urge you to try to win the war, not only the battle… Thus my 10th and for now final tip is worded like this:

Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

You can be sure no-one will thank you for delivering on your formal mandate, if the product you delivered does not really leave behind anything valuable or useful when the project is terminated.

For me a key aspect of project management, as well as management in general, is to pursue continuous improvement, both within the project and across all projects of the company. The more mechanistic aspects of this, with Lessons Learned logs etc., are well covered in most project management methods. But it is of course even better if you can adjust course rapidly (agile, if you will…) as the project goes along, and that is as much a question of attitude as of hefty templates.

Another classical fight is the one between short terms requirements (“give me that functionality, and give it to me now!”) and long term demands of architecture and maybe even cleaning up some old mess. Again, trying to eat the elephant in smaller pieces is key – try to build architecture project by project and if you have a large code base (and they are never only pretty), leave it just that little bit better every day. Oh, and when estimating the cost of your next project: Make sure to estimate the required time and cost to improve architecture as you conduct the project.

I am considering writing a piece about project portfolio management, arguing that this is really more than what can be achieved in a project management office or similar structures. I hope to do this sometime before Christmas. Please come back to have a look. My next piece, though – and hopefully in just a few days, will be summarizing the brief tip series of posts.

Development in software business models – and the power of hindsight

2009-10-15T20:12:00.004+02:00

When I recently was selecting a mail solution for my new company, I went for Google Apps. I did this after also considering a small business edition of Exchange, as well as just continuing to use the built in email service from my domain hosting provider that I already had up and running. Also my current client, i.e. my previous employer Inspera, has moved to Google Apps from an in-house Exchange solution, they just finished the transition last weekend.

These two decisions made me think back to what I wrote in my thesis on software business models in 2007 (part of my MTM degree, an MBA in technology management from NTNU, MIT Sloan and NHH - link to full foreword/abstract is provided for anyone interested):

…[even if] there is no “one size fits all” for business models in the software industry, if I had to place one bet on which business model innovation that will have most impact based on my findings, my decision would be clear: My money would be put on SaaS – on-demand subscription based software. Predicting paradigm shifts is a risky business, and especially so with shifts that have been predicted similarly without really happening before. Nevertheless, my take is that enough enabling factors have changed so even if it will not replace the traditional license, it may radically change the way software is sold, distributed and developed the coming years.

So the million dollar question is: Is this actually happening for mainstream applications for mainstream companies as we speak?

Extrapolating from the two samples (yep, two years since I last touched academia and reading the daily Dilbert since...) the conclusion has to be: “Sure”. On the other hand, I have also worked for some big companies over the last year that just wouldn't even start to consider Google Apps. But still, major changes in buying patterns often start with smaller companies and over time becomes an option also for the larger enterprises requiring time-tested and mature solutions.

Even if I feel the last two years have added support to my hypothesis of a possible “disruption from below” ala Christensen, I think the jury is still out on the question if SaaS will replace the traditional license based model as the dominant model at any point – or just be a supplement. (And to me financing a traditional license – making it look somewhat like a subscription – does not make it SaaS, by the way.) Cynics might also add that the predictions of net-PCs given in 1998 are not much different from the SaaS and “everything in the cloud” visions of today, they might argue that it has been coming in large scale “real soon now” for over ten years...

Reading the abstract two years after also drew my attention to another thing I wrote, that ...lines between data, applications, software and services can sometimes be blurry. This I at least think is even truer today than it was in 2007 – or to ask rhetorically: Is Twitter worth a zillion because of its software?

A twitter-er with no tweets...

2009-10-15T19:04:00.003+02:00

Although I feel a certain degree of ambivalence towards the (near) real time aspect of Twitter, I have finally given in and registered - after one of my generally very insightful colleagues (a dedicated non-fan of Facebook, BTW) insisted it was very interesting and even useful.

I have no ambitions in the directions of real time updates of what I do (my life just isn't that interesting), but hope to take part in some interesting discussions.

My twitter ID is pmmonkey. Will probably keep my read-to-write ratio high going forward, but maybe time to post that virgin tweet now anyway...

PMMonkey goes entrepreneurial (again)

2009-09-22T15:20:00.003+02:00

I have recently started my own company, Innovation Consulting - the formal registration went through last week after quite a bit of paperwork. My first project is helping setting up an offshore development centre for Norwegian software vendor Inspera (that I used for work for, as CTO and later VP of Consulting) and their partner in Romania.

I am not yet sure if this will be a temporary thing with only myself, or if I will hire other extraordinary people and try to make the company scale. What I do know is that I am available as part-time advisor if you have exciting and challenging projects in the first half of 2010 :-), as I have commited to the above mentioned project until August 2010.

Brief tip 9: Ensure buy-in and reconfirm along the way

2009-08-27T09:58:00.005+02:00

Wow, a new post not that long after the previous. Another brief tip coming up, which is is simply going to be worded like this:

Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on

The first part might be too self-evident, but make a mental note of the second part. It is in fact easy to forget this in the spur of the moment, and a project can often be nothing but a long sequence of hectic moments. Taking the time to involve key stakeholders, getting their opinions and buy-in (adjusting the course as required) will give you back the effort tenfold later – which may in turn contribute to more control of the hectic moments later in the project...

I think the tip is relevant on both a team level and an executive level. On the executive level, you might find yourself trying to mitigate different and conflicting interests. When this is not feasible, you hopefully have set up escalation mechanisms to get to a decision and move forward. This process also ties closely back to the second PM brief tip of managing expectations closely.

On a team level, reconfirming tasks, responsibilities and estimates are all important. This will also be a self-reinforcing loop, as team members tend to take on more responsibility when given the trust. Of course, you will have to work hard to create a context where the likelihood of succeeding give OK odds – if not the responsibility will be more like Scott Adams demonstrates for Dilbert as shown below:

I also think the principle of reconfirmation and no surprises can be used to contradict what some people seem to think about “that great final presentation of the project”: My take is that there is absolutely no point in such a “big bang" final presentation aimed at impressing and surprising the audience (often CxO-level). Share your thoughts (and software, if your project is developing any) early as much as possible, refine them along the way and deliver the final presentation knowing that the message will be understood.

Brief tip 8: Add value beyond administering

2009-08-21T15:06:00.003+02:00

A little while since my last post. Looking back (wine, food and beaches in Tuscany and later Spain - then a surprise U2 concert as a birthday present from my wife), I can't say I got the priorities wrong. Good project management. :-) Anyway, here is another "brief tip":

As a project manager, try to add value beyond administering the project

The last year, I have completed my PRINCE2 Foundation and Practitioner certifications. In PRINCE2 there is a pretty clear advice that the role of the project manager “…is to manage, not to do”. While I see it as important that the project manager don’t loose her view of the big picture because of working on details, I actually think that it usually works better if the project manager can add some subject matter expertise or otherwise contribute beyond administering the project.

Some project managers have a technical background before being promoted to their own level of incompetence (the Dilbert Principle in all its beautiful essence). For these, taking part in architectural roles or detailed design may be a good way to be involved beyond the project administration. Others may contribute to testing, others again will have a strong hand on the business case and marketing plans.

I think you get some things for free if you as a project manager participate actively in the project (“doing”, if you will…). For instance if you take a role as a tester[2], you get project content and status under the skin “for free” that you would otherwise have actively worked to obtain.

For the team to see that the project manager is working along them (a Scrum master might very well be a developer for the most part of his time) can also be motivating and it shortens distances for communication and makes it easier for the project manager to detect problems early through informal channels.

[1] – PRINCE2 is a trademark of the Office of Government and Commerce in the UK and other countries

[2] – I do agree with PRINCE2 that the project manager should not be the same person as responsible for quality assurance though. If at all possible, it will make life easier for everyone knowing that there is two different persons filling those roles.

Brief tip 7: Choose your checkpoints

2009-05-20T22:01:00.003+02:00

In my current job at PA, we have checkpoints, forms and procedures to ensure quality and avoid taking too much risk. That is all very fine if you have the machinery to handle that, as is the case with PA. But what if you don’t? I think you still need some sort of checkpoints (often commercially focused), even when you operate using agile methods.

I’d like to share with you what we ended up with when selecting some checkpoints for our projects at Inspera and hope you will find it useful. These are, more or less, the mandatory checkpoints we ended up with:

Starting work on a proposal
Delivering a proposal
Project initiation/kick-off
Periodical reporting of progress and budgets (here it was monthly, YMMV)
Project sign-off, with a simple client satisfaction survey and handover to maintenance

What if you are not ready even for this level of formalism? If I should keep just two checkpoints, I think I’d go for proposal delivery (Who approves this in your company? Rules of thumbs for estimate breakdowns? Have cross-project coordination of resources been taken into account?) and of course sign-off. This would probably be in a very small environment where surveillance of risk and project status would be done rather hands on by the general manager anyway.

I guess one wording of this tip could be:

Establish checkpoints that you follow in each of your projects, even if operating in an agile way

“Even in an agile way” might sound strange, but while the almost automatic checkpoint built into many agile processes (such as the sprint review) can be combined with commercial ones, that does not happen automatically.

That was my tip #7, written at Bremen airport in Germany - traveling to Belgium this weekend with my wife who currently works in the Netherlands. If you don’t agree or have something to add, please leave a comment.

Contract templates as project placebo

2009-05-20T20:19:00.001+02:00

There was recently an article in the Norwegian (and Norwegian language) publication Computerworld claiming that the legal framework, which was based on a template from the construction business, had helped making a large IT project successful. I wrote a response to this, together with colleague Jakob Markussen, that you can read here (Norwegian).

We put forward that project management techniques including risk management, well-defined processes, iterative development, and last but not least the collaboration and communication is more important than the legal framework template that is chosen for a project. After all, as any of us that have struggled with contracts know, the real work is in the appendices – and if you don’t have to revisit details of the contract to resolve conflicts, even better!

Brief tip 6: Do the hard things early

2009-04-06T09:43:00.004+02:00

As I mentioned, agile methods have some built-in capability of reducing risk by having a working version early and improving it in increments. In my experience getting an early version up often uncovers miscommunication and can minimize the cost of this.

However, I have found, both using cousins of Scrum and occasionally also methods maybe best described as the evil twin of the waterfall process (!), that there is often a tendency to postpone the hard tasks that we do not know how to handle. Don’t.

In fact, I’d like to advice as my tip #6:

Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one

Starting working on the hard tasks early has multiple advantages, which include:

You learn more about the problem domain early on, often this helps finding the final solution even if it will not be finalized until a later iteration.
Often the hardest tasks in a software development project involve complex integrations and multiple parties. Then it is often length of the calendar time that is required, with the hot potato being passed around, and not so much the number of hours worked that will help. Also the effect of adding more resource when already late has been questioned all the time since the seventies (“Mythical man month”, anyone?).
Some times the hardest tasks are actually not possible (or at least not feasible) to solve. Finding the workaround or even scrapping the project or functionality early is so much better.

That was my tip #6. Please leave any comments below. My best wishes for the Easter also go out to everyone stumbling across my blog.

Brief tip 5: Use a visual risk log as a communication tool

2009-03-12T13:28:00.006+01:00

Risk is most often defined as uncertainty of outcome (both PRINCE2 and PMBOK stress that both negative and positive impacts are considered risks). As a project manager you cannot always find appropriate actions to mitigate risks, but you should be sure to communicate your view of risks and their status.

One of the great things about agile methods is that they have a built-in capability of reducing risk by working in small increments. Nevertheless, risk management is sometimes overlooked by Scrum-masters and the like that was “born agile” that does not have the classical, old fashioned if you will, project pyramid theory under the skin. I actually think this is an area where the agile movement can be supplemented by methods from more traditional methods, such as PRINCE2 or PMBOK.

The steps in risk management are really quite straightforward: 1) Identify risks 2) Classify them 3) Select appropriate actions. I think it is important to separate risk identification and classification. If you don’t, the risk (pun intended) of prematurely ignoring a risk as already handled or not understanding its impact if happening it is too great. Risk classification will vary from project to project and organization to organization, but impact, probability and proximity (in time) will be safe bets as a starting point. Needless to say, the risk log should be a live document that you keep updated throughout the project – I would say that a weekly review is a minimum.

If you set up the format of your risk log, be it a formal risk log of your favourite project management method or a more informal overview you keep for yourself, in a practical way, you can automatically view the risks visually. I have found this to be a good tool for communicating the status of risks to project boards and the like. Below is a risk matrix for this blog post created by such a setup:

I have uploaded the excel sheet that I used to create the above graph. I hope you find it useful. As mentioned, I think the risk log and resulting matrix can be a great communication tool – even if the exact computation of impact and probability is not very sound mathematically. The idea is of course both to keep an overview, but also to move the risks down and to the left. But don’t let the matrix lull you into a false sense of control, of course.

That was my tip #5. If you don’t agree, please leave a comment. Oh and I almost forgot to formulate the actual tip, here goes:

Keep a close eye on risks throughout the project and use a visual risk log as a communication tool

Brief tip 4: Communicate early, communicate often

2009-02-19T16:43:00.005+01:00

This tip is simply:

You can never communicate too much as a project manager

You should communicate clearly, often and repeat important messages even after you think everyone knows every little detail of it. They don’t. This is not because they are lazy or forget easily, it is just that most often they have not had the information internalized through lengthy discussions or working on the issue for a long time.

When the first members of the team smiles ironically when you repeat the message, you are not even half way through. When team starts to make jokes or even parodies of your most repeated messages, I would argue you are probably about three-quarters through getting a message out to everyone that will be sticky.

I also believe in sharing whatever information you have with the team early, even if you are still waiting for a conclusion of an external discussion. Even if one can argue that this can be confusing for the team sometimes, I feel it builds trust. Also, you avoid running into situations where you are unsure what you can say based on what you have said before. If you don’t do it, you will sometime have to make priorities that are hard to understand for the team. So I think saying “this is all that I currently know and I will share it now” is usually the best way of handling it.

This philosophy plays well with a notion of involving the team in decisions and to be able to make rapid adjustments of direction. You can formulate the principle of over-communication as a virtue the way I do in the title of this post: Communicate early, communicate often. As an added bonus, a little word play back to one of the principles of agile software development. :-)

That was my tip #4. If you don’t agree or would have ranked it differently, please leave a comment.

Brief tip 3: Now, write that down

2009-01-30T12:54:00.004+01:00

Even if you use lightweight methods, which can be an excellent choice, with less focus on documentation it does NOT mean that you abandon writing down conclusions from meetings, internal discussions or how a difficult project issue was agreed to be handled. My most basic, but maybe the most useful, tip is:

Be sure to put conclusions in writing immediately, even if not using documentation heavy methods

I find over and over in projects that same discussions will be repeated throughout the project because participants are unsure what was concluded. To settle a discussion can sometimes be hard and time consuming work. Then you ought to think that writing it down and sending it by email just “to confirm and summarize my understanding of the conclusion” would be easy and done at once? The next time, do it.

Writing down conclusions is equally useful for internal architectural discussions and for external commercial ones. This is also related to the previous point about expectations and mutual understanding. You have the chance to use the power of definition. Your customer or your team will even thank you for it most of the time. Writing things down to document decisions will help you tremendously delivering projects, agile or not – it is what consultants like to call quick wins or low-hanging fruits.

That was my tip #3. Now go pick those fruits. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 2: Manage those expectations!

2009-01-16T12:16:00.007+01:00

Excuse me for the use of the exclamation mark in the title. I promise not to do it again, but as this point was beaten to the #1 spot, I just had to do it. :-) I can’t say strongly enough how important I feel this is.

Let’s take a slightly academic approach. Let’s say that customer satisfaction relies primarily on:
1) What the customer expects
2) What you deliver in your project

Now, how long do you spend doing 1) and 2) during the whole life cycle of the project? Seriously, do think about it for a minute. I have found that it can sometimes be extreme. That holds true both on a project level, but also on the micro level – haven’t you sometimes spent hundreds of hours tweaking a feature that the customer didn’t actually find that important? Could you maybe just have negotiated that out, perhaps giving something more valuable with less work in return?

Typically I find that way too little time and effort is spent on managing expectations. One way to uncover misaligned expectations is to be explicit about what you are NOT planning to deliver or do. Expectation management is not an one-off in an early phase, but something that you continue to do at every chance all the way until the project is signed off. Thus I formulate my tip #2 as:

Be sure to use every chance throughout the project to manage expectations

The process of managing the expectations all the way through the project is not only to the benefit of the supplier. Another expression for managing the expectations could actually be to really understand the customer’s needs. So if it is more politically correct, feel free to change the title of the point to “ensure mutual understanding”…

You can talk about managing expectations internally as well (for instance for the team or line management if you are in a matrix organization environment), but I won’t do that here.

That was my tip #2. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 1: Don’t forget the people

2009-01-12T14:32:00.005+01:00

I promised to deliver the tips in a roughly prioritized order. Thus, I had to start with this one – especially since most of my other tips will be somewhat more focused towards the harder aspects of delivering successful projects. So tip number one is:

Do not forget that it is the people in the project teams that actually deliver successful projects

The softer skills, needed to foster a team environment everyone will enjoy, contribute to project success at least as much as methods, templates and processes do. Motivated and happy team members run in circles around their dissatisfied and demoralized cousins! They take responsibilities and grow in a self-reinforcing virtuous circle. When you have gained trust early on in the project, they start raising issues as early as they even begin to sense them, instead of just before they blow up on you all.

Often the role of the project manager will be more of a facilitator than a more traditional manager. Also, if you operate in an environment and/or framework that command traditional top-down thinking, getting the balance right with bottom-up empowerment is important.

You should not only cultivate your team internally. Remembering to take good care of people and show a behaviour that helps people feel valued are equally important when dealing with people outside the team, for instance the customer if you are a supplier. If you run intro trouble, and almost any project of a significant size will at some point during its lifecycle, it will be so much easier to settle and move on if you already have established a platform of trust and maybe even a type of friendship with the client at this point.

And by the way: Don't try faking it. You will get caught and nothing will destroy carefully earned trust faster. So you have to really love your job and care about your team...

That was my tip #1. I look forward to read any comments, but you will have a hard time arguing that people are not important – even if you can present hard facts or rankings to back them up (this is one of my top five favorite Dilbert strips of all time, taken from “The Dilbert Principle” book by Scott Adams):

Introducing the “Brief tip” series

2009-01-12T14:23:00.000+01:00

I am today kicking of a series of posts, aiming at a total of maybe 10, containing practical tips for day-to-day work managing projects in general and software development projects in particular.

Some of the posts will include a specific tool, procedure or checklist, but most will be more general in nature. Hopefully they will all be thought-provoking. After all, I do not believe in any silver bullet procedure for ensuring top quality project management or software development. That being said, procedures and checklists can help a top quality project manager when used with thought. :-)

I will be writing the posts in a roughly prioritized order (meaning that I write a piece when I find the time and about a topic not yet covered!). I hope you will find them useful, and look forward to your comments even if you don’t agree, or maybe particularly if that is the case.

The missing link between management information and agile methods

2009-01-07T09:28:00.009+01:00

It is now pretty much accepted, and to some degree starting to be confirmed by actual empirical data, that agile software development can lead to better bang-for-the-buck than the traditional requirements gathering -> analyze -> design -> develop -> test iterations with comprehensive documentation in each step of each iteration. The concept is rather simple: Do not spend time on details you are unsure will have value, and always make incremental improvements to a working product that you get up and running as quickly as you can.

Also, by involving the product owner directly in prioritizing product features, adapting to changing customer requirements will be built into the process. Another element of many of the agile methods is cross-functional and often self-managed teams that respond to a changing environment, rather than following a detailed plan. When you think of it, the conceptual leap from lean manufacturing as perfected by Toyota to agile software development is maybe not that large – at least not in underlying principles.

But, even if the customer’s senior management accepts the notion of increased value and efficiency through flexibility, they are often not willing to accept the notion of just developing in a broad direction to create as much valued functionality as possible until the money runs out. Some more structured planning and reporting is expected. So how do you handle this as a project manager? This is the topic of this post and I will not go any more into the details of agile methods as such here.

Often the solution chosen, if you cannot get the customer to choose an all agile approach (which I believe in practice often means a time and material type contract), will be a hybrid. Pragmatic as I am, this is an approach I have used in some of my projects. The problem is that this often results in a missing link between the software development process and the management information. This leads to the classical situation so often captured in the Dilbert cartoon, where engineers and management live in two distinct worlds with little communication coming across with the intended information still present…

This presents you as a project manager with two challenges:

How to translate the legal obligations and high level plans into meaningful guiding for the day-to-day work for your developers, without falling back to a detailed pyramid of specifications and the team spending a too large part of its time producing documentation that will not be used
How to translate the actual work done and progress made into a world with more structured plans with fixed milestones

These challenges are of course not new, but what makes them different than just a work breakdown type of task is that the details of what happens in the execution step is not planned upfront. It thus take a lot of skill to be able to agree the right high level milestones, so that they can be reached using agile methods for the actual execution. It really is a challenge to be as specific as necessary for the customer to be confident the value will be delivered as agreed, but not so specific that it kills the whole concept of agility upfront. In my view, this is maybe more an art than a science – so I am afraid I can provide no simple checklist to achieve that goal, but it helps to know that it is a challenge and think about it upfront.

And there is no reason to paint it all black. It is indeed possible to provide those missing links. For instance the burndown charts and list of completed issues of Scrum in the agile world provide excellent input for a Highlight Report in the structured planning world of PRINCE2. Similarly breaking down a PRINCE2 Stage Plan into a product (and later sprint) backlog of Scrum or a similar method can work just fine. However, there is of course tension between the different basic philosophies that you should discuss with your client. But as long as your client buys in to the idea that you actually deliver more and more relevant products, even if she might not be willing to let go of more traditional planning, I think that this hybrid model can work better than not trying to achieve any of the benefits of agile software development at all.

Agility as a more general term is certainly a key treat for a project manager to be successful. However, my take is that the toolkit of the agile software development movement often fall way short of covering what the customer needs to feel comfortable with her project. To avoid the situation with the missing link, the project manager must be comfortable operating in both worlds and tie them together in a coherent whole, while enjoying the trust of both the developers and the customer. Then the situation will hopefully not be exactly as Scott Adams sees it below:

I have heard some argue that the role of the project manager is obsolete when moving to agile/lightweight software development methods. I’d like to argue that it is more important than ever, but more demanding – as you have to be comfortable in a broader span of processes and skills than before. I will probably return to the role of the project manager and the mapping to roles in Scrum in a later post (should she be the scrummaster or the product owner do you think?).

Remember what Keynes once wrote: It is better to be roughly right, than precisely wrong. Agile methods are a way of achieving just that, but the direction you go must be managed along the way and senior level management may not want to adapt 100% to this new way of working. As the project manager, you thus have to be the translator and understand both worlds – in other words be, or at least provide, the missing link proposed by the title of this blog post.

Let me know what you think by leaving any comments you have below. As always, I hope to learn a lot from them.

Alignment of project dimensions: A balancing act

2009-01-02T09:49:00.014+01:00

When writing the promised piece on agile methods and management information, I found that I wanted to present some thoughts about alignment of different dimensions of projects to avoid having to make the other article longer than necessary. Thus this post first.

I have found it useful to think about the alignment of some project dimensions before signing the contract and kicking off the project. The dimensions I will consider here are contractual terms (pricing), collaboration and strength of relationship, and the software development method to be used. Your selection of variables may vary, but I insist that trying to take such a bird’s eye view is useful when assessing the risk of project failure.

Below (click to see it in full size) is four actual projects placed in these dimensions. They are all software development projects, but differ somewhat in terms of complexity of integrations, amount of front end vs. back end programming, etc. as well as size. So they are by no means a perfect academic sample set, but they are projects that I know because I have worked and lived them.

As you might guess from the topic header, my hypothesis is that some combinations of the dimensions fit better together than others. Which of the projects above would you be afraid of taking on as project manager or team member? Which did you think get into trouble?

In retrospect, one of the possible “doomed to fail” projects actually didn’t (number 4). I try to cover the reason why in my next post. The other prime suspect, number 3, did actually fail spectacularly in terms of profitability. In fact, I took over this project midway (that is when just about 110% of the budget was used…) and even without drawing out the diagrams, the missing alignment was striking. However, the end product developed was to the customer’s satisfaction and new projects will be conducted that hopefully will be better business as well.

Another way of viewing the above dimensions could be in a 2x2 matrix (I am currently a consultant, after all!). Below I have tried to do that, with development method on the vertical axis and contract/pricing horizontally. The color (blue=”colder” customer/supplier relationship, red=strong partnership) of the dot indicates the form of collaboration, to avoid fiddling with three dimensions.

In danger of over-simplifying, I’d like to make the following remarks about these quadrants:

The bottom left quadrant is just fine, although maybe a little bit old-fashioned. You could consider discussing with the client if a more flexible approach could be more suitable (moving up and right in the chart) and delivering more value.
You should be extremely careful if you are in the upper left quadrant. You must then be absolutely sure that you and your client have found a good way to manage scope adjustments. I would also never conduct a project in this space if it is not a strong relationship with the client, i.e. a "red dot" above. Without these two in place, this is the “doomed to fail”-quadrant.
The upper right quadrant if the place you probably want to be operating most of the time with agile methods. Especially with a strong relationship with your client (red dot). Be sure to manage expectations both upfront and at every increment, though. Often it doesn’t help to have the legal contract on your side if your most important client is not close to satisfied after all funds are burnt doing iterative improvements.
The lower right quadrant is probably just fine, but it indicates that although there is client/supplier trust, indicated by the choice of time&material pricing, there is actually no belief in the gains promised by agile development methods. Thus, one gets the formal overhead without really needing it to handle pricing and legal issues. But formal specifications can absolutely be a way to handle the expectations management mentioned in the previous bullet point. Some target price regimes might fall into this quadrant, but not all (for example, project 4 was a target price regime).

Another related way of looking at this, is through the classical project management pyramid – TRQ, time, resources and quality/scope. The basic idea is that you cannot change one without adjusting the other accordingly. So if you fixate time and cost, certainly the details of scope can be a variable throughout the project. This view fits quite nicely with what DSDM preaches and on the development level this is the way I find working with Scrum-like approaches most fruitful.

Of course, my comments about the sample projects at this point are with the power of perfect hindsight. But let’s look again at project number 3, where we obviously tried to do flexible development with slim specifications with a completely new customer (collaboration form is not always a function of length of the relationship, but the two are usually strongly correlated and in this case it was a new customer) at a fixed price as if it was a classical waterfall approach we were using. Was it very likely to succeed if judged upfront? I think not.

Please do not read my comments only as a way for vendors to maximize their profits and minimize their risks. The assessments of the project dimensions should rather be discussed openly with the client before kicking off the project. It is after really understanding your customer’s need you will be able to make the best trade-offs for that particular case. Project management methods, and legal contracts for that matter, has large elements of tailoring after all.

There is a lot of fuzz about the specifics of each agile method proposed. Maybe too much. To me, agile software development is actually just as much about mindset and approach as it is about specific methods. And I do think that one should make sure that the mindset and the more formal frameworks (contract, form of collaboration and actual development methods being the three sampled here) match and discuss this upfront between customer and supplier.

In an earlier draft, I considered using project size as one of the variables. This could easily have been included for example through the size of the dots in the diagram notation. I considered about 10 projects I had managed myself and a few others that I know fairly well and I did not really see size (ranging from a few hundred to many thousand hours) being as important as the variables I have proposed above when considering if agile methods will be suited. But you might beg to differ? Let me know what you think by leaving any comments you have below. I hope to learn a lot from them.

About me

2008-12-30T22:35:00.010+01:00

My name is Sondre Skaug Bjørnebekk, and I thought it would be appropriate to write a few words introducing myself. When interviewing for the job I currently have, I ended up saying in one of the interviews that I probably have the brain of an engineer and the soul of a salesman... While this may sound terrible to some (“Do salesmen even have souls?”, I hear some shout in the back), it is probably not that far from the truth. If you add a touch of enthusiasm and entrepreneurship mixed with hard work (we are descendants of the puritans that moved north, after all...) you are about there.

I hold an MSc degree in computer science from NTNU (the Norwegian University of Technology and Science) and an MBA in technology management from NTNU and MIT Sloan. For some more details and hard facts, you may visit my LinkedIn profile.

I used to be software architect, then CTO and later VP of Consulting at a small (but steadily growing!) Norwegian ISV, Inspera. Currently I work as a Principle Consultant with the PA Consulting Group. All views expressed in this blog are my own and not necessarily related at all to those of my employer.

At Inspera, I managed projects of various size and complexity – some large ones with several thousand hours of development, coordination between different vendors and subcontractors as well as optimizing product development along with customer specific projects – interesting and challenging indeed. As head of the project department, I was also trying to formalize the knowhow of my project managers and developers on what worked and what didn’t in trying to deliver successful and profitable projects.

I have also run my own, very small, company since 1998. There I’ve developed various pieces of software including a recruitment portal, webshops and games for mobile devices and currently this is where I can still get my hands dirty and not only be a project management monkey, but sometimes even a code monkey! In addition to my main work at PA and the side activity in Webmagi, I serve as a board member at Inspera.

On the personal side I have been married for a little more than five years. We are voluntarily without children at this point and living in Oslo, Norway – right here in fact.

I think that’s it about me. My next post will be the first with some real project management related content. It will be about the need I have often found to connect the world of software development with lightweight or agile methods, with the expectations of structured reporting and overview often found in customer organizations. I hope to publish that one the coming Friday, January 2nd.

What’s in a name?

2008-12-30T11:46:00.001+01:00

During my time in the software business I have heard the term “code monkey” several times. Sometimes it has been in a negative, patronizing tone. Other times it has been uttered with an ironic touch, often with quite a bit of pride, by the developer doing the actual “monkey work”. In my world this type of work is not at all dirty, but a form of art – comparable to the finest furniture carpenters or perhaps of designing and building Swiss clocks from scratch that will then work perfectly “forever”.

My belief is that the role of the developer is not as any kind of slave to the project manager. In fact, it is rather the opposite way around – the role of the project manager is to make sure any obstacles (impediments, if you want to Scrumify this a bit) that stops the developers building great software are removed as quickly as possible. In this light, it is the project manager that is the slave of the developers – the real stars of any software development project – and thus the name of my blog, The Project Management Monkey.

Welcome to my blog about project management and related topics

2008-12-30T10:28:00.005+01:00

This is my very first attempt at a blog, which can be found a projectmanagementmonkey.com or just pmmonkey.com for short. After more than ten years in the Internet and software industry, you might want to consider me late or even slow. Or maybe I’ve just been busy. I think that sounds better, let’s go with busy.

My focus will be on IT-related projects, both software development and other types. The focal point of my interest is on the linking of business and technology, so this is also probably where most of the topics of my writings will be. I might also write some pieces on other stuff more or less related that interests me, such as software business models and negotiations. My aim is that the content should be of practical use, and actually change the way you view, participate in and manage projects.

I am not very ambitious in terms of volume of articles, but I will try to post a handful of small articles during 2009. I also have a little idea for some very short and practical oriented pieces called “Brief Tip” that I hope you’ll find useful.

I look forward to learn from your comments.

Welcome to my blog.