maalekar

I haven't posted here in quite a while. I buried myself in Microsoft for a year and a half. This turned out to be the biggest career mistake and waste of time I have ever had. In reality, their employees, with the exception of their software engineering teams, are fodder for the chain gun that is the management structure. The entirety of that organization is designed to protect the long timers despite their failures and to cycle through 1 to 3 year people like popcorn in a movie theater. I've not been so professionally insulted in all my life.

If anyone reading my blog is considering working for MS... don't. You will be sorely disappointed. Unless the entirety of the senior management team is swept clean the kind of changes that need to happen there will NEVER happen.

I posted this somewhere else back in April 2009. It's interesting that this Context Based Communications is becoming the hallmark of effective collaboration tools.


Let me explain this...
Context Based Communications: All forms of communications get marked for the content they bring to related projects or programs so that it is not lost in the mess that is email.
AW: workflow that automatically notifies you of changes to timelines and objectives within projects.
TAWTS: workflow that has the abilty to track progress and report as an effectiveness rating AND has a mechanism to track the talents brought by individuals for assignment and acknowledgement purposes in an organization.

I see the various companies in common corporate land (MS, Cisco, Avaya, Apple and for my first time entering them Google). They all have their own ideas on how they can differentiate themselves. None of them, except MS, like the status quo (i.e. MS owning the desktop and therefore the advantage). They all want something to change there. The issue... legacy apps. What they forget is while they are out trying to get the developer base to change where they develop MS offers them a clear pathway to make money... without waiting years to see results. The reality is that, as well, Web 2.0 has not played out to advantage yet for most base workings of the common user in corporate IT. People don't want to log into their word processor, spreadsheet, etc... not yet, they want it now without connectivity necessary.

This will, of course, change over time as it becomes CHEAPER to do so and still maintain corporate acceptability for security and compliance purposes... but that will take a MAJOR change in either interpretation of the law or a willingness in corp-world to take a bit more risk (which, as we all know in the consulting biz, is the antithesis of the posture at most company's legal and security personnel).

I guess what I am saying is that, in the end, security and legal hold the chains. They can make or break a company's future by either working to increase capability while reducing risk or avert risk thereby anchoring a company in computing dead space. Could it be, in the long run, that these 'chains' become anchors that sink companies eventually? I have to ponder that a bit longer...

In consulting the practice of driving business is the key to success. What does that mean however? Many say the words but don't do the deed.

What it means is driving an effort through demonstrable business change. That business change is made relevant by aligning the effort with the level of the business that one is working with:

CxO: The CxO level wants to hear how the effort will hit the bottom line of the organization in both monetary and strategic ways. This means discussing how the objective grants long term capability delivery that is needed to make the business more agile and future ready as well as the ROM (rough order of magnitude) financial impact.

Upper Management of IT: How does the effort impact the line of responsibility for the area of management? If this question can be answered clearly, monetarily, and helps to align their area of influence with the goals of the CxO level then it is clearly worth doing. Assurance that the effort will be managed and the objectives CLEARLY MEASURED for success will guarantee forward motion. The objectives being measured MUST be accepted by this level before the effort starts so that success can be validated.

Middle Management of IT: This group is usually interested in assuring that their area of coverage will have solid impact by the effort. Total costs must be considered including:
* What are they paying now for every aspect of the current service?
* How will the effort impact the end service?
* How much will it cost to transfer to the new service and how long will it take?
* How does this solution or effort deliver on the goals set for them by their management?

Remember that time costs money in your calculations and that alignment with overall strategic vision for Upper IT management is important.

Line of Business Management: If you are lucky enough to get a hold of this level of business management you can build a business case for your project that truly solves for the needs of the business overall. In my 23 years of consulting IT is ALWAYS in the way of access of this group. The tendency is for IT management to not let others speak to them for fear of being perceived as inferior. The three ways I have seen access to this group are as follows:
* The upper management of IT is progressive and will work with outside organizations to assist them in developing the strategy that delivers to the needs of the LOB.
* The upper management of IT has failed enough for the LOB management to demand access to other opinions.
* The consultant helps to make IT management the 'rock star' in the effort that delivers to the LOB and plays a background role.

There are certainly other ways of gaining access but they are limited and rare.

Anyway, my thoughts for the day... for now.

I'm not feeling the 'love' lately...

It's always good and bad. You made it another year without a meteor coming down and crushing you randomly.

Happy Birthday sir. My best.

I've started heavy reading and listening to the messages from the big educational machines in places like Harvard, Princeton, and Dartmouth regarding business/technology innovation. Many of the principles that are described within are directly in line with the way we work innovation at my current client, P&G.

It seemed natural to me to work in this fashion. I suppose the challenge is to take what is natural and create ideas that carry forward to the next step. In other words, taking these ideas to the next step is true creation rather than reiteration of today's picture of what innovation is and how it is executed.

Hmmm.... alright. Now to postulate:

Innovation Leader and advisors; create the initial concept: The leader should be one or two steps below the executive sponsor at most. The leader should have a broad background in technology, not a specialist, but with many years of experience that span IT technologies, business, and management experiences. Initial program build should be assisted by a limited number of trusted advisors. After the initial ideas are formulated the directives should be used as framework and the process used to drive Innovation to the goals created by the initial concept.

Directives:

• The group should consist of designated IT leaders in architecture, members of business units potentially impacted quickly by the effort, and must have a strong executive sponsor that is either the CIO or a direct report that has the cooperation of the CIO.
• During the process, always reiterate the ideas and goals in the group. Make sure the same story is being told by all and that all participants make effort to reach out to their constituents.
• Feel free to veer should a high-value target be identified but remain focused on how it fits into the original concept definition.
• Mistakes and failure should be expected and learned from. There WILL be lost time. These failures should be understood by the entire group and used as learnings in future Innovation efforts as well.

Innovation Process:

• Phase 1: Controlled Chaos is the best way to create ideas with groups. Appoint leads of small groups to ideas and tell them to run free within their ideas. As the overall lead of the effort you should never truly know everything that is going on. If you do then you are providing too much control in the process. Ideas should be freely discussed, examined, and then brought forward to the larger group once most of the examination of functionality, form, user experience, and potential business cases are thought through.
• Phase 2: Solidified Ideas should be examined by architectural people for technical review and commentary on risk and by business analysts to assure the validity of the cases involved. Security/Legal/Compliance must have a representative to examine and document any potential aspects that would halt the program and begin the process of examination of any identified issues.
• Phase 3: Create the technical building blocks primarily in production (prep for a pilot). The pilot building blocks should be scalable to eventual enterprise levels, not built to be replaced. Save lab for anything that would have potential risk to the production environment. The S/L/C leader in innovation must represent the risk to the associated inlife groups as a comparison to the risks already held by the organization (failure to do so will create perceived risk where there is none).
• Phase 4: Create a pilot program using 'friends and family' of the Innovation Team and associated business units. This team should EXPECT changes that could reset their environment entirely and should be willing to work with the consequences. The pilot should include a small subset of leaders in the business units associated with the business cases developed in Phase 1 to provide actual end user feedback (rather than just IT user feedback). Assessment of Pilot success should be on clear lines of both usability and applicability to the business cases identified.
• Phase 5: At the half-way point of pilot life the intersection between inlife and innovation begins. The leaders that are relevant to the pilot should combine with a designated inlife team to build the concepts for support, sustainability, and expansion into the enterprise. This IS the hand-off point for the majority of the innovation team. Ideas for inlife support as a service is at this point documented by this group and handed off to the inlife group for enterprise build and deployment . As well, the Lines of Business leaders involved should be building deployment methods into the business processes once the inlife plan is made and timelines for enterprise deployment are developed.

Alright, i have to think about this now.

You tell me... I'm at the cutting edge of technology from a business perspective yet I cannot see the cats herding in the right direction...

Bah, just a bad day... not in the mood.

Tired today... I could have slept another few hours.

I think i need a vacation or some downtime of some sort.

So motion continues... The work moves on...

Is there anybody out there?