Blog

Louis Barkan

In-House Solutions Architect: Ensuring Success Post Hand-Off

August 24th, 2011

Strategy, UX Design

With a deep background in Custom Application development, NavigationArts’ Senior Consultant, Karl Woods, approaches user experience (UX) consulting engagements with a keen focus on the client’s technology environment – specifically, where it stands, where it’s going, and how we can best align our practices with client needs. In my interview with Karl, I wanted to gain an overall understanding of how clients can better prepare for, and maximize the value from, a UX engagement.

Lou Barkan:  Here’s a hypothetical situation.  Some company, X, decides to invest in a UX project due to increased competition in a crowded market.  The client is looking to create a portal and unifying UX layer across a series of hosted applications and disparate systems that comprise a core product offering.  This UX layer will be hosted in their CMS, which is simultaneously undergoing platform level changes. What should that company be doing to best prepare for a UX engagement?

Karl Woods:  Whenever I begin a consulting engagement, I encourage the client to look at their overall internal team dynamics.  I ask them to assess who within their technical team can be dubbed a technical lead or, more appropriately, a Solutions Architect (SA), to act as a point person or project liaison with the consultant.  That individual will be responsible for communicating, from a purely technical perspective, the client expectations.

LB:  What general qualities does an SA have?

KW: An in-house SA (or technical lead) needs to have strong written and verbal communication skills, as well as a thorough understanding of their IT architecture, including all the touch points within their system and who owns or is responsible for them.   Typically, this is someone who also has a good rapport with the other IT teams within their company.

In the case you’ve outlined, the person who owns the CMS needs to be the gatekeeper, especially if there is a significant amount of system and platform level development going on.  As the “host,” the CMS leader is the person best positioned to identify the internal teams that would need to make the project a success.  Therefore, he is the best person to assume the role of SA.

LB:  So even if a company doesn’t have an official “Solutions Architect,” every project needs someone who is going to act like the SA?

KW: That’s exactly right. And in addition to possessing those qualities I mentioned before, I’d also highly recommend that the SA have a strong understanding of HTML, JSP and CSS, because those are the code components that the client receives and has to work with moving forward.  Ideally, the SA would also have a thorough understanding of the technologies present across his own system.  Ultimately, clients want a consultant to deliver code that is a spot on match to their in-house standards, or at least extremely close to it.  To accomplish this, the SA first needs to know what technology exists in-house.

The SA must also work with the consultant in preparing the rest of the organization for the transition.  In this example, the SA would align internal groups with the CMS team and give them an opportunity to provide feedback and input on their expectations from the engagement.

Clearly,  there are a lot of moving parts.  Other infrastructure elements and components are in play and in flux. All of those things need to be built out to support the portal framework, which leads me to what I love to see: an internally vetted strategic IT/development roadmap that shows all the IT projects and initiatives a client has underway and who is responsible for which pieces.  The roadmap would include the strategic project plan to build out the entire portal and enable the team to better manage expectations and risk factors.

LB:  And what’s the purpose of this roadmap?  How do clients use it to their advantage?

KW: Within a client’s own IT group, the roadmap represents the primary plan they drive from.  So, the consultant’s plan for the UX engagement really acts as a parallel development model. The roadmap very simply allows a client to know what is being built in tandem across their domain and where the intersections of all this work are coming together.

For example, a client’s in-house application coders are going to have to start doing their development upon receipt of the templates from the consulting UX team.  With this in mind, the client will want to use their roadmap and strategic project plan to align internal work and make sure the portal framework is in place to receive what the consultant delivers. As the UX team goes through its analysis and design phases, the client also should be identifying all those areas which will allow them to start to work on an implementation plan.  This way, the client will know exactly how they are going to roll out any code we’re delivering. Which brings me to another point:

Clients really need to stand up a development environment.   This cannot just be created in production.  The portal should be created in dev with other environments available for testing, proofing out designs or concepts.

LB: What’s the benefit of the client having their own development environment?

KW: It’s the sandbox.  It’s where clients get to work out a lot of the bugs.  Most importantly, it allows a client to create, after initial development, a deployment package.  From that point, a team can test how to best roll into production and avoid costly mistakes.

LB: Apart from having an SA and strategic roadmap, how does the client remain engaged throughout the project?

KW: As a consultant, I always make sure the client SA is attuned to project specifics.  I also suggest the client allocate an internal PM to work alongside our team and attend meetings.  If the SA can’t attend, reviewing meeting minutes, action items, and responding to questions immediately is crucial.

LB: What’s the danger of not responding soon enough to issues that arise?

KW: If a client raises a valid issue about a task 2 weeks after that task is closed out, then there is going to be a schedule impact.  Clients, and especially all in-house team leaders, need to be aware of the project schedule, which is owned and published by the consultant.  It’s our job to make the client aware of dates, especially sign off dates.  If a client is required to sign off by a certain date, then they should be working backwards from that date to allocate review time.  Without excuses, feedback must be returned in a timely manner.

LB: Of course the danger in not understanding and/or losing resourcing is damaging the institutional knowledge that has been baked into the project from day 1.

KW: Absolutely.  Internal client team leaders must assume responsibility as well as ownership and be the subject-matter-expert (SME) for their area.  I expect them to be fully engaged in anything dealing with a major degree of complexity.  So, if we are working through a piece of challenging or complex functionality, it would be the client’s responsibility to ensure a representative from their core team is collaborating on the resolution with me.  I’ll have ensured that person fully understands the solution to be passed off, which reduces confusion once the project has been handed off and we begin our post-consultation relationship.

LB: What can clients do to ensure a smooth hand-off?

KW: Well, much of that responsibility lies within my team, but it also relates to my relationship with the SA. I always work with the SA to ensure he or she is involved in any major technical decisions. From hardware upgrades to web tier, oracle, cloud, etc, the SA must be involved. I work with the SA as a lead developer and an analyst.

LB: Any other final thoughts?

KW: As an SA or part of the SA’s team, be clear and concise so consultants can help you validate your thoughts.  Develope a strong in-house team capable of working effectively post hand-off, and remain engaged with the consultant’s Client Services team to ensure issues are resolved quickly.