Rating a ‘B’ in a Project Delivery Sanity Test

February 23, 2008

Most people in our industry recognize that ThoughtWorks is one of the leading software consulting companies today. A lot of this can easily be attributed to the number of superstars present in the company – the number of books, papers, talks and podcasts that emanate from there are testament to the same. When one of them writes (or speaks), we stop to read (or listen). So when one of them puts up a checklist of items that will likely decide the success or failure of a project, I decided to take the test to see how our project ranks (I won’t bother trying to decide if the checklist itself is accurate or not).

1. A Delivery Focus (B-)

There are two parts to this question. I definitely think our feature set gets built with a usability focus though I don’t think we satisfy the tjme-constraints he sets out for getting software into production. We have definitely gotten much better at this over the past year but still a-ways off from ideal.

2. Clear Priorities (A-)

I think our priorities (though always subject to change) are pretty clearly understood within the team. When they become muddled, we take time out to ensure everybody’s on the same page.

3. Stakeholder Involvement (D)

I have always thought this has been our weakest attribute to date. The funny thing is that focus has always been on improving this feature of our software development process and a different approach is taken each cycle, with nothing major to show for it. The biggest issue is the lack of a true product-owner. Again, hopefully that’s changing for the good as well.

4. Business Analysis (C+)

I might be way off on this one – the problem is that I don’t get to see the business analysis. And truth be told, I would probably not understand it too well either. This might easily be an A-. I hope it is.

5. Team Size and Structure (A)

This is one of our strong suits, definitely.

6. Planning and Tracking (A-)

I would have thought we would get A on this one, but with Amit’s definition of this criterion and his emphasis on getting software in the hands of the customer as early as possible, I think we lack a bit in that area.

7. Technical Architecture (B)

Atleast with the code I work in – the architecture bit itself is quite good – and we refactor as and when required (and not just for the sake of it). Yet, the build times are absolutely horrendous and hinder developer productivity. We are taking efforts now to cut down on the build times but until we do, its only a solid B.

8. Testing, QA practices (B-)

An A+ for our testing practices, but a non-existent QA department.

9. Understanding software development (A+)

Definitely the strongest attribute. Everybody who is in a managerial position definitely understands software development and are on the same page as the devs.

I know some of my workmates read this blog, so I’d definitely be interested in knowing whether you agree with these metrics (more or less) and whether you would grade any differently. What do you think?


One comment

  1. Really interesting post Rags, I think shorter delivery cycles would increase our delivery focus. This doesn’t have to mean shorter planning cycles, but doing code drops and integration testing will drive this mark up.

    I think the rest of the marks are pretty good and realistic.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: