Expression is the act of defining (or re-defining) the project vocabulary.
This is the most advanced of the five areas of competence that I described (engagement, fluency, comprehension, implication and nuance, and expression). I struggled to define it well in my original post. I think expression is the ability to effectively define the vocabulary of the project, to give names and categories to things that were chaotic and unorganized. It is a key part of developing a project strategy that allows incremental delivery, to create affinity groups of features and give them names. Here’s an example:
A business person gives you a list of features they want a web app to have, in no particular order and with no particular grouping of the features. It might be something like this:
I’ve seen lists like this that go on for pages – it can be daunting and seem chaotic. Taking this unorganized list of features and making it manageable is an act of expression, because you group those features in affinity sets, which is a fancy way of saying that you take similar features and group them together. Here’s one way you might start grouping the features above:
User Support
Contact customer service by email
Have a live chat with a CSR
User Enrollment
Verify new user’s identities using existing account information
Account Management
Change account informat (address, phone, etc)
Make a payment
View a statement
I didn’t do a complete decomp of the first list – this is just an example to help explain what I mean by expression. One of the things that I’ve seen happen when I am able to use expression well is that it inspires a re-thinking of the requirements so far. For instance, I would expect a business person to look at User Enrollment and say something like “you know, there’s a lot more to user enrollment than just verifying identity.” Then, we would add stuff to that list.
We also prioritize the groups, and start planning iterations to implement the high priority items. This is also an act of expression, because you are starting to turn the list of features into something more – an implementation strategy.
Competence Pie
I like to model concepts visually, and I’ve come up with a model for perceiving and building competence – I call it competence pie.
Others Need to See Your Competence if it’s Going to Benefit You
Being the manager of a project is not just about being competent. You have to be competent – faking it is a short term strategy that will eventually fail if you don’t use it to buy time to build real competence. That said, being perceived as competent is also critical. You need to demonstrate your competence to your business partners, your project team, and your IT management if you want your project to be successful. They need to have confidence in you. Not building that confidence will open the door to a host of troubles, including micro-management, dissent on the technical team, and poor collaboration with the business.
Build real competence, and show it.

0 responses so far ↓
There are no comments yet...Kick things off by filling out the form below.
Leave a Comment