Update: some folks on our team let me know that the tone of this post seems very negative. That's not my intention, and this project is still going great Heavy handedness aside, what I'm trying to communicate is that it is important to think about everyone that needs to live with a technology solution , not just the actual users. And Agile needs to accommodate this truth. That is all.

Sometimes a project at Innova reminds me that we don't do everything particularly well.  I'm always glad when we can get back to building sensible technology solutions, but it would be a mistake not to learn something from these tough experiences.

We began a new project for a major long-term client with our typical high-level system specification.  Standard practice for us, this artifact of our design process describes the use cases which led to the system spec, and sketches out a preliminary interface through a rough prototype implemented as html.  In our normal Agile practice, this document helps get everyone on the same page at the start of a project, and it is gradually "taken over" by a working system.  

This process works, and our customer had experienced it repeatedly.  The thing was, on this project, we were working with the IT group-in the past, we've always worked with business units at this client.

IT departments have different priorities than business groups.  Whereas business folks care about development time (minimizing it, that is), usability, and strategic advantage, an IT group may be more focused on fitting a solution into their support organization.  This means they don't want heterogeneity in technologies, and they don't want approaches that make auditors and future bosses raise their eyebrows.  In short, they want to buy IBM.

Which is fine.  We use stable, mature technologies and think our software is among the best designed in the industry, using high levels of code separation, DRY, and a predictable MVC design pattern.  But that's not what this post is about.

This post is about the difficulty we've had communicating that our solution meets the needs of the IT group too. So, where did we go wrong?  I think the answer is simple–we didn't consider the IT folks in our user-centered design documents.  We forgot that they're users too.  Not in the traditional sense, but in a kind of meta-sense–just like others, they have unique goals, and a design that doesn't accommodate their needs will fail.  Similarly, a design that doesn't communicate its efficacy for these meta-users won't get purchased.

Here are some things we'll think about next time when considering meta-user needs:

• Is the customer comfortable with the technology approach?  To be clear:  Can the customer defend the technology approach to people who might criticize it?
• Does the project allow everyone to feel like a respected, useful contributor?
• Is the customer comfortable with their role in training and support?
• Does the customer feel that their resources are used as fully as possible to drive down cost and aid in knowledge transfer?
• Will the project result in the required artifacts needed for things like Sarbanes Oxley, regulatory compliance, and professional standards?  Have we made life easy by packaging these up for the client properly?
• Does the project align with mission statements, charters, and organizational budgets?
• Are the stake-holders comfortable that they'll know where the project stands at all times?
• And most importantly:  Did we listen carefully to everyone?  Are we confident we know what each stakeholder needs to make this project a success?
  

After writing  for these use cases, we'll be careful to communicate the plan clearly and slowly, making sure everyone understands.

Part of being a professional is aligning your actions with the customer's needs.  Adopting an Agile development approach without consideration for meta-user needs is the kind of Agile development that gives the whole process a bad name.  And the kind of business practice that is sure to lose contracts.