To "Hit the Ground Running", cut the chute first.

So, you created an impressive resume; a good relevant cover letter; got the interview call and you've bagged the job offer. Or may be you're just starting on a new project/role in your organization. And they need you to "Hit the ground running".  A common expectation these days, given that the recruiters/selectors are very specific about the skill-sets and "attitude-set" they look for. And most of us believe that all your past experiences, the success stories, list of achievements, experience with a vast number of situations will enable you to do that - "hit the ground running"

Quite surprisingly, that's not true very often. Your past success stories, achievements and testimonials together formed the parachute that helped you land in this position. The job of that chute was to land you safely. But now you need to start running. And you can't run with the chute on, can  you? To start running, you need to cut lose of the chute. And quite often, we forget that important step before trying to run.

Most of us have had, or worked with people with rich experience that promises an exciting future. Only to realize that that very past forms the excess baggage hampering the performance. The key I think is to un-learn and then start learning. Here's a three-pointer that I've seen work in most cases:

1. Start with an open mind-set. Don't try to categorize your current role/situation into one of your past buckets. Usually this manifests as - "Oh this project/situation is like the one I worked on with XYZ client. Let me begin with the approach that worked there." While that may be one of the right solutions, it may still not fit onto the bigger picture, or not align with the strategic direction or not take the existing constraints into account.

2. Once you have cut the chute, know where you are. Start with active listening and probing through targeted questions. Focus on "WHY" rather than "WHAT". Once you understand the WHY - the business motivation or the drivers, its easier to get the direction correct. And once you've got the direction right, picking up pace is easier. We wouldn't want to run fast in the wrong direction, would we?

For those like me in the Enterprise architecture space, BPMN talks about the Business Motivation Model . That's a good place to start.

3. And lastly - the feedback-loop. Keep reviewing your understanding and priorities of the drivers & constraints to adapt to changing situations. Being an agile enthusiast, I have realized the power of repetitive review and course adjustments. Its a great tool to ensure you're addressing the right concerns the right way.

Good-luck with your new role!

Image credits: http://www.picgifs.com/

SOA & Project Management

Now that's a strange combination. Why should I, as an #enterprise architect, be concerned about project management? And from the other end, why should I, as a project manager, bother about #SOA (or whatever friggin technology the project is about)? Well, the short answer - SCOPE.

SOA is an enterprise architecture paradigm, enterprise-wide architecture-principles within which the technology solutions should be implemented. To maintain an efficient  architecture, it pays to be consistent across the enterprise. Which is why, SOA can provide an enterprise-wide view of the solution guideline. The 30,000 feet view of how should the  "right" solution look like. The scope for SOA, therefore, is the entire enterprise. That of course, once the definition of enterprise is established.

Projects, by definition, have a more closely and clearly defined scope within that enterprise universe. These are therefore a subset of the enterprise wide SOA scope. Now that's simple. So what's the big deal ? Things get trickier to manage when it comes to delivery timelines for the projects. The architecture can well be an evolving and improving entity, with no clear or stringent timeline requirement. Its primarily about doing the right thing. While the project needs to be delivered in a defined time-frame, and within a defined budget. Project level decisions are governed by project level factors like timelines, budgets, resources etc. Since the architecture has a wider scope, more often than not, the architecture changes and decisions interfere with the project delivery. 

That's when usually the project sponsors put their foot down and start dictating the way forward. From there on, its a power tussle. A "win-lose" or "zero sum" game rather than a game with a possible win-win outcome. The manager with more political muscle takes over. Exceptions are made in the processes. Architectural principles are bent to manage delivery. And while the delivery of the project/program gets done, there's a good chance that what's delivered becomes "Technical Debt" well before its life expectancy. I'm sure we've all seen cases where a model based service design and implementation was forgone to make way for a quick fix point-to-point solution to meet the delivery timelines. And the very next project in the pipeline would have an additional piece of work to build an adapter around this solution to make it compatible with the overall solution. And the story goes on.

So what's the solution? Simply put, the harder it is to follow the rules, more the possibility of the rules being broken. Its imperative then for the #EA to be quick and clear on defining and socializing a minimal basic standard and guideline to be followed, leaving enough room beyond that for the projects to chose an implementation pattern. A "Strategy Pattern" is a good (although simplistic) example of that balance. Have a checklist to define  and evaluate (financially & operationally) if a technical solution is a long term "technical asset" or "technical debt". If a solution takes a deviation from the architectural guidelines, and still qualifies as technical asset, all good. Because in the end, the business stakeholders are interested only in ensuring that a solution gets delivered within a cost and time frame. The level of perfection for that solution is immaterial to them. Which is why Delivery usually scores over perfection.

More on the "How" part of the solution in my coming posts.


PS: In broad terms, this is essentially the gap in an organization's #Strategy function and its Implementation function. "Architecture" being the enabler for alignment to strategy, and "Project Management"  being the management of a specific piece of work under that umbrella. In this particular case its about "Project Management For SOA implementation" vis-a-vis "Project Management Vs SOA"