Innovation through UX

This blog post by Jen has attracted my attention... I will probably state the obvious the same way Matt is good at doing (so he claims)... ;-)

Jen's post makes it obvious to me that the UX phase in a project might very well be the "easy" way to innovate in a project.  By comparison to a project without UX.  Here is why. 

First, software engineering people are mostly concerned about construction of the software.  Their focus is delivering the code.   

Second, software engineering people are... software people., this is their expertise. Many of these guys will be concerned by usability or innovation but this is not their primary focus.  They are first and foremost experts at software technology, tools, languages, software design patterns, mostly software creation centric stuff... (I believe for most of them at least)

Our UX team is by contrast much more in touch with the research world, it seems to be a natural aspect of their role to be aware of what is out there so they can integrate these academic projects into a real projects. 

In the example brought up by Jen it is clear that a software engineer could have thought of the multi-vibration thing but probably without awareness of the research project done in a particular university.  It would probably be a "wouldn't it be cool" kind of enlightment.  

As valid as this "wouldn't it be cool" idea might be it would lack the link to the academic research and would probably be much harder to sell if at all possible.

 

    

Tasks in Gmail!

Finally!  This is a premature post because since I have not played with it very much yet but in case you did not notice that it was added recently, now you know!

The one sad thing is I have not found a way to import from RTM... That's going to be annoying... Hang on... Google API... Mmm nothing there yet... 

This is to my knowledge one of the key feature that was missing to the "Google way" to email...

ProjectTools part of the InfoWorld 2008 Top 100 IT Innovative Products

What a nice way to start the day! Yesterday Macadamian was awarded one of the top 100 company that have made use of technology to enhance their business.

Somewhere back in 2004 we started to be concerned by the effort that was required to be effective at project startup, monitoring and status reporting.

We envisionned that it would be a real challenge to provision all our projects with the apprioriate knowledge management technologies and to monitor them with consistency.

With now more than 100 projects starting and ending every year we can say thanks to this early vision. Needless to say that the pressure at being efficient and predictable was high and this is still an important concern at Macadamian.

"Let's automate all that". Our concern for efficiency and predictability gave birth to what we called Project Tools. What is Project Tools?

Project Tool is a software product that aims at:

1. Automating the innitiation of our project's knowledge management infrastructure (KMI). All tools needed for our projects are ready to go in no time (issue tracking, wiki, source control, mailing list, news groups, SFTP, continuous integration, IRC, etc...)
   
2. Managing access control towards all system of the KMI
3. Collecting projects progression metrics.
4. Reporting objective information on progression.
   

It is outside the scope of this blog post to go deeper about what it is, how it works and so on.

Today I want to say kuddos to everyone who contributed to this project.

Thanks to you Francois, Pierre, Benoit, Sebastien, Jake, Jimmy, Richard, Rafy, Karen & Irina. It would not have been possible to achieve this without you.

Last but not least, this award would not exists without Teresa who submitted ProjectTools to InfoWorld. Thanks to you!

Predictability and objective historical information

Over the last two weeks I have been involved at the process of interviewing project managers for an coming project.

A few positive things are striking me:

1. Eloquence. All the guys I have talked to seems to have a facility at talking. This is not a skill you can filter from their résumés. You expect this from a PM but I was expecting some to be weaker on this front.
   
2. Deep understanding of what they did. Although their experiences were high level project management (not technical) they would all be able to describe in a fair amount of details the projects they worked on. That's good.
   

However, a few not as positive things are striking me too:

1. Predictability. Let's face it, software projects are slipping for many reasons. However as a project manager you want to reach a point at which you will know with a rather high level of certainty when you will be completed. Periodically pushing back the delivery date is a bad thing both internaly and externaly. None of the guys have brought this up. It feel like this is even not a word they know about. It's like if this is external to them, don't shoot the messenger kind of attitude. I think this is wrong.
   
2. Historical Information. When talking about estimation, re-forecasting and schedule slippage one would hope that historical information is valued as a way to improve predictability. Apparently not.
   
3. Subjective info is king. Last but not least, it would seem that very few metrics are being used by the people I have talked to. This surprises me, they all had some form of PM certifications. What if the people that brings you back the info are bad at estimating? This one beats me.
   

Obviously, maybe the questions I have asked were misinterpreted, but I am telling you I did all I could to get them to tell me about predictability, historical and objective information.

The lesson here to me is that we will have to train this new project manager to consider looking at the past to improve predictability.

After all, this is rather simple thing to do. Take your velocity/productivity/burnrate (call it however you want) and apply this to the remaining work to do. Chances are that the estimation mistake you made so far are existing in the up coming work too.

With this approach, at least, you have an objective basis for the project change (feature, time, $$) you will have, like it or not, to ask for.

This is so 1990

Sometimes I just can believe how people are getting stuck in their comfort zone. In this case, using folders as THE way of organizing email. I was 100% sure that this debate was over now, that folders (and trees of these) were bad, one of these evil creation of software people.

Coincidentally, I have a draft blog post which is totally the opposite of this guy's perspective. There is no way I could have been more effective at dealing with my Inbox content when I came back from vacation than through the Gmail client. (note that I have not tried Yahoo recently - last news was that this was simply another Outlook on the web)

His discussion on the whole unmanageable Inbox made me laugh too! Effective handling of incomming emails can be imroved through the use a powerful email client but most importantly I believe it is process thing. Looks like he did not buy into the Zero inbox concept I am referring to here.

I need to publish this "Back From Vacation" blog post...

GPS for software team

I referred to my vacation in one of my recent post. We left NYC on a Monday at around 19h. That was fun. Thanks to my GPS.

It reminded me my father who, 20 years ago, got lost while attempting to leave NYC. He ended up in the Bronx (or was it Harlem?). He luckily got assistance from a police man, who told him something like "follow me I will escort you out of here, do not stop if you do not want to loose all you have with you". He was driving a shiny mini van full of bells and whistles. A quite scary moment for a unilingual Quebecois.

This made me realize that we have several tools at Macadamian that serves the same purpose to a team than a GPS to a driver.

The most important is probably what we refer to as the "Remaining Effort" graph.

With the assumption that:

• All substantial tasks are recorded in the tasks system
• Tasks life cycle is followed
  
• Time spent on the project is recorded in the time sheet system
  

This graph shows a quite accurate representation of the remaining effort and the remaining time budget for a project.

In the case of the project above, the team has been beating the estimates throughout the project. The remaining effort - red line - was always below the budgeted effort - green line.

When this happens, we are in for a nice and smooth ride. Obviously, we also have cases where our estimates are wrong. It is then, that we - and our customers - get the most value out of our project progression monitoring technology.

Obviously, this graph is not telling which direction to take but it is at least telling you that you are on the wrong track and this, sooner than later.

Estimation

I am receiving the news letter from the TechRepublic. Most of the time I am only reading the titles and move on. Yesterday an article attracted my attention.

Use a pilot project to confirm estimates and lessen risks.

That is interesting in the context they describe where they have a project involving the execution of a task many times. If you made a substantial mistake at estimating the repeated task, sure you will slip big time.

In my humble opinion what is important with estimates is that:

1. You estimate everything you do.
2. You get everyone involved in the estimation process, especially the ones doing the work. This way your whole organization improves on this front.
   

Last but not least: you give exposure to your estimate and make it clear that they serve a purpose: being predictable.