TechSharp [T#] Going beyond Architecture Center of Excellence

Consulting Services companies goes through multitude of challenges in its Sales cycle, Delivery Cycle and over all Competency building and maintaining cycle. In this 2 part blog, I write about the various issues, Well whats the point in discussing problems with out a solution, Worry Not, The blog culminates with a tried and tested solution.

Tried Architecture as Shared Services? Felt like Abstracting the best of the resources, while encapsulating them well within at the same time? Tried creating COE’s?  Have the management shot back stating it is overused/abused concept, tried and failed? Yes there are lot of reasons to fail when NOT done right.

This blog entry documents the RIGHT way, tried and tested Recursively.

Introduction

What is TechSharp? Why do we need it? Is it an Architecture center of excellence? What is its significance? What issues does it resolve or even prevent from happening in the first place? Who benefits from it? What are the levels of Architecture maturity model?

 “Inside every problem lies an opportunity”  - Robert Kiyosaki

Problem Statement

Figure 1 : Summary of consulting problems

The three pillars of Services Companies are:

1.      Sales

2.     Delivery

3.     Technical Competency

With the ever changing technology landscape – Quantum Computing, Complex event processing, 3D printing, prescriptive analytics, predictive analytics, augmented reality, Internet of things, Cloud computing, etc.  . . . , keeping up to it is always challenging

Sales:  

Having a great sales force will get the clients interested in anything, making sure they are trained and are provided with relevant information is quite important.

Getting an initial meeting – easy peasy ? We all know that isn’t the case… Compare it to converting the meeting to an opportunity ! ! ! First and foremost, the sales force needs the right technical expertise accompanying them, right case studies, bringing the right people together, asking the right questions, a lot of persistence and a whole lot of perseverance, the client is now interested, but you aren’t the only one. . There are 4 others chosen to submit an RFP !

Submission timeframe too small:  Have skilled resources available to get the RFP on time, Need to depict a very detailed solution architecture, clearly define the technology stack, identify the existing resources, identify the availability of the resources for the project, availability of the skill set internally and in the market, Estimate the cost for the project along with the time line, assumptions, risk and other project management goodies. .

Need the best people presenting the RFP

“Can we please have an architect more so an Enterprise Architect” ! ! !

Delivery:

Won a project, Hurray mails sent ! !

Client wants to get started immediately, well somehow managed to get 6 to 8 weeks time, Forming a team with-in the time frame not always the easiest. Unable to find the resources on time, especially niche skills, start compromising for average resources, Never a good idea. . Is it?

The client had provided an indication on price, the estimated price is way higher.. Do we need an architect? X, Do we need 5 resources? X let’s make it 3, Do we need so many resources onsite? X lets have them all offshore, and so it goes on.. ending with Projects without Architects,  No thorough requirements follow through, New team thinks the RFP is under-estimated, The team members who were part of the RFP or the entire process have changed and there was no transition. The delivery believes that the effort is still underestimated, the management thinks enough buffer has been added.. whatever that means..  Margins are covered? All set to go !

There is no standard proactive external Audits and Governance in place

Flawed estimation techniques in place

Agile methodology being used, and the client is driving most of the requirements, the project members are way too involved losing the track on the architecturally significant components, architecture debt on the project is creeping up.

The initial discussions were with the C-level folks, being a smaller company there aren’t any technical representatives from the company. The company has appointed a product owner, who is very clear about the current project requirements however doesn’t have a clear vision on the roadmap of the company, the product is about to be out,  the C level folks are now being demoed and they want to see the same on their device, It doesn’t work ! ! That was not in scope. Well the blame is always on the vendor, rightly so?

There is an architect in the team who talks to the business analyst for the requirements, there is client services team who have good relation with the client, and the business analyst have good relation. The technical relationship is however missing completely. The architect is not too articulate in sharing the ideas which could have contributed to the extension of the project. The architect is driving most of the things with-out any external governance, and out of emergency the architect had to leave. NO STRONG TECHNICAL RELATIONSHIP, SINGLE POINTS OF FAILURE ! !

The team is working on a new tool, language, framework, etc for which the org has not created a standards/best practice document yet.

There are multiple projects/case studies using a particular technology stack, however every new project the team starts from scratch. There is knowledge base, best practices document which are 100+ pages, none of the teams bother to read through them. The best practices have not been updated forever. A new project manager wants to implement standards however looking at how old it is, discards it, now it is up to the team’s capability. There are also no reusable frameworks, other teams have used the same exact stack, overcome quite a few hurdles, however each team learns the same lessons. It is like part of the non-optional syllabus! ! ! 

Performance issues, we have been trying this forever not able to fix it, can we get some consultants to help us, client is complaining about the overall quality of the product, architect says this is the most optimal architecture and client says it is far from it, client has called for external audit to review the architecture identified security gaps, client had clearly provided instructions that the software needs to be SAAS enabled, cloud ready, however the test performed was no different from the traditional development initial test in the cloud was a disaster !

A mandate to follow agile. The team is still getting used to the paradigm. It is quite interesting, planning poker cards, story points, daily scrum, retrospectives, backlog refinement, sprint reviews and Quality group has set other processes around code reviews, check in comments, continuous deployment and integration, and however there is no architecture governance as part of the process, and the client isn’t always available so the business analyst has been made the product owner. Process gaps

            Every project manager will have faced the resourcing dread, and that’s an understatement. Starting from getting together the team, to managing the time, to managing attrition, the extended notice periods, the sudden drop outs, week end interview drives, getting a skilled resource needs a good interview process and a technically good resource following the process.

“Can we have architects please?”

Tech Competency:

Great team, Geeks, intellectuals, problem solvers, go to guys, enthusiastic, love what they do.

Time is THE only limiting factor..

A great developer might have a potential to be a great lead, a great architect or just continue to be a greater developer in not only one area but in multiple, be able to pick up new skills and excel in it. However, the projects are taking all the time and is getting impacted by the issues listed in the delivery area, having to spend ++ hours apart from the regular time, NO time to up-skill. Have you had people stuck in projects for years, how about 5, 6. . Well if there is a project for that long, All is well lol J

Org does not have programs to help upgrade the resources.

Some might really be exited to even let go of the work life balance philosophy and spend time to learn the niche, emerging technical skills, however there aren’t labs or environment/facilities that enable them to do so, their interest may take them only so far

Org has a subscription to websites which provides basic training, and it is also licensed on number of users, so there is a limit to share the same. Did I emphasize on BASIC. The invite/subscription is extended to only those who are interested. Some of them don’t end up using it at all. Time constraints. Others don’t get the subscription, too busy to even show interest.

What skill training is being offered? Are they in alignment with the Org’s roadmap? Where does the cost for the training go? The client pays for some if they have introduced new skills, the division or the BU takes care of a few, the corporate takes care of a few. Which skills should all these investments go in to?

Should the Org be providing the basic training? .Net, Java still? Cant that be mandated as part of the hiring?

There are resources who know where they stand but, that would be in their own perspective, there are NO benchmarks for self-assessments. Org having a view of these assessments is also great. Setting goals for appraisals, putting together a career plan, having training courses etc as part of the goal setting exercise, the software used for performance appraisal, NOT so mature.

There are No clearly defined R & R

Summary table of issues/problems

Issues	Category
Shortage of people	Sales
Solution Definition (Includes Team formation)	Sales
Context based Technical Questionnaire for the client	Sales
Estimation Challenges	Sales
Pre-Sales team to Delivery team Transition	Sales
Quality of Pre-Sales documents	Sales
Tech Competency	Sales
Communication/Process gaps	Sales
No knowledge of the client roadmap (team)	Sales
Understanding the roadmap of the client	Delivery
Define Standards/Compliance	Delivery
Architectural Tools/Reusable framework	Delivery
Identifying and Highlighting the solution risk	Delivery
Proactive and continued Solution review/Audit	Delivery
Requirements follow through	Delivery
Overall Solution Quality	Delivery
Team formation/People Availability	Delivery
Defining and owning the Technical Ownership	Delivery
Overseeing projects without Architects	Delivery
Establishing and managing client technical relationship	Delivery
Performance of the application	Delivery
Estimation gaps	Delivery
Clearly defined R & R	Delivery
Interview Process	Tech Competency
Assessment of skills	Tech Competency
Update to existing skill database and gaps	Tech Competency
Availability of skilled people	Tech Competency
New skill building	Tech Competency
Lack of environment/Lab to learn	Tech Competency
Lack of knowledge on the organizations technology direction	Tech Competency
Lack of a well-defined career growth	Tech Competency

View the Solution here