I recently had the unique opportunity to chat one on one with a highly experienced CIO with a history of managing IT large shops. It was a fascinating conversation and eventually it wandered to the evolution of corporate IT in larger companies. At one point in the discussion, he started drawing on a whiteboard as he was describing his perspective. The whiteboard picture was a great way to visualize the IT transformations over the decades. In a break from my series on helping engineers get their great ideas to resonate with senior management, I’ve captured that discussion here including the visuals and added some additional perspectives as that conversation has stuck with me over the subsequent weeks.

Through the 80′s = Specialization

This graphic reflects various company business units with their IT function and staffing reporting directly into the business unit itself. As an example, the Human Resources business unit has their own “HR IT” department that is a completely self sufficient group of individuals with all of the tools and ability to support all the needs of the HR business unit. From basic helpdesk/PC support through server/application support and new application development needs, “HR IT” can and does do it all.

90′s to 00′s = Centralization

As depicted in this graphic, this decade of corporate computing reflects a great centralization effort across the industry. Company leadership noticed they were paying people in “HR IT” to say, fix PCs, as well as additional people with the same skill-set in “Finance IT” to fix PCs. Also, it was becoming more obvious that fixing PCs wasn’t a unique skill-set, rather, the same skill-set that could be sourced from a central team. Pooling the skill-set enabled an aggregate reduction in head count. If all department IT PC fixers totaled, say, 10, then a central PC fixing team could deliver the same level of service with, say, 7 people. Thus, cost savings became a big driver for this large scale organizational change over this decade for pretty much all IT functions.

The change wasn’t without pain. Business unit individuals were used to having an IT need and literally walk down the hall to “Bob the IT guy” and get immediate service. Once Bob became part of a central team, one could no longer just reach out to Bob and get that immediate high touch service. One had to call a “helpdesk” and report the need. Then the “helpdesk” assigned a request “ticket” number to the need. Next, the requester was informed of the “SLA” (service level agreement) to which their need would be serviced. Instead of bringing your broken mouse to Bob to have him pull a replacement from a cabinet and hand it to you immediately, you were told a new mouse replacement was on its way and should arrive within 24 hours or something clearly not as immediate.

This began a huge cultural shift in the business/IT relationship. In times prior, Bob was viewed as a trusted member of the business unit who knew everyone, knew the business, knew the priorities, and even knew the applications sometimes more thoroughly than the business users themselves. Bob knew that Sally got really frustrated with technology and needed extra time and attention. Bob knew that Jim had zero patience and would flip out if his needs weren’t met immediately. As IT became ever more centralized through out the decade, all of Bob’s high touch, high value service was getting replaced with narrowly defined IT “services”. Business users began experiencing “high call volume” delays and “We no longer provide that service” and “We can provide that service. Can we get your manager to sign off on the $X charge back?” IT became increasingly viewed as just a service provider.

I am going to date myself as I began my IT career seeing first hand this service provider transformation. I was “Bob” providing high touch, high quality service getting constantly re-organized into a more and more centralized IT functions. I saw the business user’s frustration grow and the quality of service plummet. I also appreciated that it was a necessity. The cost to provide high touch service wouldn’t scale to meet the business demand for IT in any sustainable manner from a balance sheet operating cost perspective.

This rise in IT being viewed as a “commodity” service provider that was increasing disconnected from the business gave way to the other IT trend in the 90′s: outsourcing. Once IT was a commodity, the next logical management thought process was: “Why should all these expensive IT people be employees? Why not shift them to contractors as well as shift a bunch of fixed cost to variable cost on the balance sheet?” IT already had plenty of contractors to supplement permanent staff with specialized skills. Shifting IT management to consulting firms also removes the complexities of aligning staff skill sets to rapidly expanding technology innovations plus reduces the IT HR overhead as well. Thus the 90s saw significant, large scale, IT outsourcing activities.

I personally went through such an outsourcing experience early in my career. I started as an actual department IT employee and then got caught up in the centralization activities followed by a massive outsourcing effort. Over nine years I probably had a new boss and a new reporting structure every six months. The company went from many thousands of IT employees world wide to literally 127 over the course of four to five years. I remember that specific number because it was such a dramatic transition (which is worthy of its own blog article). I also had five employers over those nine years as each wave of outsourcing involved larger and larger IT outsourcing firms

00′s to 10′s = Repair the damage

This decade for IT was equally disruptive as the prior. The wide spread use of the Internet created whole new marketplaces and opportunities for companies to get revenue from new products and services continued to drive up demand for IT. The dot-com crash brought a much needed fiscal correction to the fundamentally flawed business models of some Internet birthed companies. Though unfathomable at the time, in hindsight, a company has to make revenue at some point or the finite capital funding will shift to those that can demonstrate profit making ability. Yet, not everything IT was Internet related. There was still a need to operationally support the non-Internet activities of a company. Business folks were growing ever dissatisfied with IT services. IT, considered a commodity, had established the reputation for being big, slow, expensive, unable to change and unable to deliver on time. CIOs and IT leadership knew they had to fix this great divide of what was seemingly the business versus IT and IT versus the business.

As I’ve depicted in the graphic above, IT, still centralized, begins to repair the “relationship” with the business by adding new roles that bring IT closer to the business. Business executives complained to IT executives that they don’t know how to engage IT for services nor do they know how to escalate issues for effective resolution nor have a mechanism to ensure IT is working on their most important needs. Thus new IT roles like “business relationship managers/executives” are created. These roles involve highly polished communicators that know how to talk business to business people and enough IT to quickly navigate the monstrous IT organization to bridge the gaps. The business versus IT tension begins to reduce. Relationship roles expand to provide more people to address different levels and expectations within the business. Project management expands into program and portfolio management. Relationship managers now present a “book of business” or a “portfolio dashboard” to keep their business partners informed of what IT is working on and delivering for them.

You’ll also notice the size of the business units is shrinking. As IT continues to automate human activities, the business needs less humans. IT continues to grow to meet the demands of the business for automation. The actual total company employee count, in aggregate, starts to show and consistent and continuing declination trend.

For more on this people versus automation theme, I strongly encourage you to read the books and articles from Andrew McAfee at MIT’s Sloan School of Business as he has some phenomenal research and perspectives on this topic.

Towards the end of the decade and prior to the US financial collapse, the typical maturing IT organizational structure had delivery teams aligned to business units as well as teams grouped around common services. Developers might work for the HR aligned delivery team within IT but interact with database and platform engineers that were in a single pool reporting into a separate technology aligned management structure. I’ve tried to depict this with the almost overlapping circles between the business units and IT. IT begins the perception shift from a commodity to a trusted business partner. At the end of the decade, the US financial crisis put a screeching halt to the good progress IT and the business was making as massive staffing cuts were occurring at all levels of companies for survival.

The outsourcing waves of the 90s became less massive as those companies that did extreme outsourcing started pulling back in IT employees to fix the bruised relationship problems. A variety of pure commodity support functions (first level helpdesk, PC, server and network support for example) were still ripe for outsourcing. Another area that was ripe for outsourcing was software development and support. Low cost labor in places like India became attractive to IT management. IT failed to produce any hourly rate to quality model in the application support and development areas. Thus, from a finance perspective, it pretty much impossible to say with numbers why a $50 an hour application resource was that much better or worse than a $75 or $100 and hour resource. Thus, when an IT firm said they could provide those resources, offshore, for $20 an hour, CFOs put pressure on CIOs to take advantage of those drastic cost cutting opportunities. Thus business aligned delivery teams trying to manage employees, specialty contractors, on-shore and off-shore resources and their “book of business” with their business partners. These roles demanded strong talent to address all of these factors impacting success.

10′s – present = More disruption within IT

Although the current decade isn’t even at the halfway point, corporate IT coming out of the US financial crisis has been forced to evolve even more rapidly. IT industry buzz worthy trends such as “consumerization of IT/BYOD (bring your own device)”, “big data”, “cloud” and “cyber-everything/data breaches” have forced businesses and IT to further align and hold each other more accountable for the company’s overall success. IT itself, as I’ve tried to depict in the above graphic, is beginning to split very clearly into the portion aligned to the business and the remaining commodity portion. The business aligned portion of IT is essentially brokering the commodity portion of IT to deliver services to the business. At times, those commodity IT services are being brokered outside of the IT department itself to “cloud” providers. And, in situations where the business and IT delivery alignment isn’t crisply delivering needed value, the business is going around IT and brokering their own “cloud” provided IT services.

Within IT itself new roles are appearing to support the growing chasm between commodity IT and delivery IT. “Integration engineers/architects” represent a function that takes the application services the delivery teams needs to construct and aligns the various internal and external commodity technology components to host the application services. “Application/solution architects” expand to assemble plans to leverage existing IT assets as well as buy or build new assets. It is rare today for a corporate IT shop to embark on a completely green field software development project. So much IT solution options have been built up within companies as well as available via software companies that the majority of software development has morphed into targeted development to support the integration of existing to new purchased software components. “Enterprise architects” are looking across a wide range of project activities and trying to identify common patterns and leverage-able components so projects are less likely to build redundant technology for different business units. “Cloud integration architect/specialists” augment the knowledge of what company IT capabilities exist compared to cloud “x-as-a-service” capabilities. The IT solutions now need to consider beyond just buy or build technology to include sourcing the technology “as a service” from a “cloud” provider ss the best way to meet the business needs.

Another aspect to the business versus IT dynamic is becoming obvious. In prior decades, the business knew the business and just needed to give orders to IT to automate work flows or enhance existing automation. Thus the notion of “IT as order takers” existed where many IT organizations waited around to be told what to do by the business and then would run around and execute what the business was asking. I think, although controversial, it is increasingly more likely that those extremely aligned to the business actually know more about the business than the business. When a company’s products and services become more and more IT-like in form and function, the company’s delivery IT increasingly becomes more knowledgeable than the business because they know the IT side and have been rapidly partnering with the business in order to know the business. One supporting example would be the financial services industry. Sure, there is a significant predominance of bankers in banking, but if you look at the products a bank offers, a strong number are essentially technology in form and function (think ATMs, online and mobile banking, account to account electronic money transfers, online account opening, electronic statements, etc.). Many financial products can be researched, selected, purchased/enrolled, used, serviced and closed/terminated all digitally with a majority if not all bank back office functions technologically automated to the point that no human interaction occurs with any transactions. Hence in the graphic for this time period reflects a significant overlap between IT and the business.

Present and beyond = Continued evolution

What do the years ahead look like for corporate IT and business evolution? Not owning a crystal ball and only listening to the IT pundits, one might think corporate IT is going to disappear and the business is going to go directly to the “cloud” for all their IT needs. One can Google “end of the CIO” and scroll through the pages of articles making such claims.

I do think that that the trend of IT splitting into highly business aligned groups with a commodity/raw technology providing group is going to continue unabated. Additionally, I think there will be increased growth in business process outsourcing which, depicted as the example HR cloud bubble in the above graphic, involves not only using cloud IT services but having that cloud service provider take on more business tasks previously handled by company employees. “Commodity” business functions such as aspects of say, HR and Finance are the potential candidates for this complete business process outsourcing. Functions such as processing payroll, previously handled completely in house can now be a data file out of an HR system (potentially in the cloud itself) and into a new cloud provider to figure out who needs a check or direct deposit or a purchase card, etc. Due to the need for complex IT integrations of these services, passing data electronically between the company and cloud providers for various reconcilement needs, the business will need to partner with their IT delivery teams to effectively utilize these services. Thus, the business and IT partnership will continue rather than the cloud consuming in house IT.

Additionally, I see cloud service providers subbing out portions of their services to other cloud providers. This allows cloud providers to further optimize the cost to deliver services while at the same time increasing the contract and integration complexity for their customers. As far as public/private “hybrid” clouds, the potential for less security pressured industries, say non-enterprise software development companies, may gain “hybrid” traction. My guess is highly secure environments will grind to an almost halt with “hybrid” clouds due to the general security noise around cloud host-ers as well as all the access control, monitoring and reporting that, traditional on premise “identity and access management “ capabilities provide.

All in all, corporate IT is in constant evolution. The rate of evolution appears on all counts to be accelerating with no signs of any slowdown in the future. Anyone who isn’t prepared to have to constantly re-invent themselves should seriously consider a different career path than corporate IT.

Anyone disagree with my evolutionary perspective or future predictions?

, , , , , , , , , ,

As those that read my blog (please click on the About This Author link if you haven’t), I primarily focus on corporate IT concepts in large organizations that consume plenty of IT, but IT isn’t the company’s core product or service. Projects and project managers play the role of herding the proverbial cats in order to deliver material IT change in these large environments. With that being said, project management in large organizations tends to be exceedingly challenging. Project Management Offices are staffed with folks trying to implement appropriate processes such as Project Life-Cycles (PLC) and Software Development Life-Cycles (SDLC) with all kinds of project toll gates to try and monitor project spend as well as quality metrics and other such governance structures. Additionally, Project Managers report to Program Managers that report to Portfolio Managers and into Enterprise PMOs in these matrix-ed/dotted line organizations. On top of that, reporting structures are constantly vacillating between a central pool of project management talent everyone draws from to talent directly reporting into the IT solution delivery teams. With hundreds and thousands of IT workers all trying to get work done, implementing change while trying to maintain the stability of production services makes strong project managers critical to the successful delivery of change. Thus, when Shim Marom asked if I wanted to participate in this flashblog on the topic of “What does Project Management mean to me”, I jumped at the chance to add my voice in with all of the excellent bloggers Shim has assembled on this topic.

What does Project Management mean to me? Or …

The three attributes of IT project management that make an effective project manager stand out amongst their peers.

1. Knowledge of the PLC/SDLC, but more importantly, the processes behind the processes

An attribute that makes a project manager effective in their role in a large IT shop is knowing all of the project processes inside and out. The project manager essentially helps guide the core project team members through those formal processes such as funding tollgates, quality milestones, as well as project and technical reviews. If an engineer has to stop engineering things in order to determine what document or form they need to fill-out in order to request a review of some deliverable or artifact they don’t know needs to contain who knows what content, it adds considerable stress on to the engineer as well as adds delay and overall confusion to the project team. For a project manager to be effective, knowing these processes thoroughly is essentially table stakes in a large IT shop.

Now, what makes a project manager excel in their role is knowing all the processes behind the processes and all the people that can help move those process steps forward. The majority of these project process steps involve someone or some group that needs to hear or see certain information in they way they are used to seeing or hearing it in order to approve the project team to move forward or assign a critical resource to complete a task. For example, Sally in “Project Accounting” needs to have a certain spreadsheet filled out a certain way for these certain type of hours to be accounted for in this cell and those other hours accounted for in that other cell. When Sally gets that spreadsheet filled out in exactly the way she is used to seeing it, she can quickly push the “Approve” button in the project management system that enables, say, corporate procurement to indicate the vendor on the project will get paid and thus the vendor can start working. When Sally has to explain exactly what she needs in order to push that button, it is typically impossible to get a hold of her to join a meeting and when she does, she confuses everyone with her extreme accounting lingo that no engineer can comprehend and thus begins the rinse and repeat cycle of throwing darts at the spreadsheet in hopes you get Sally what she needs. Being able to support the project team with this critical knowledge of how to get through the “Sally-gate” with the minimum of fuss is what makes a project manager excel in a large IT shop. A project manager with this type of value add is constantly in demand and frequently requested to lead projects to the point of having to turn work away in my experience.

2. Ability to translate a technical goal into the bare minimum of project steps to complete

Another attribute of a strong project manager is their ability to understand a project team’s technical goal and be able to translate that into the bare minimum project steps to achieve that goal. Here is an example project team conversation that illuminates this attribute:

Joe Project Technical Lead = “Ok, engineer Bob just found this software component that looks to do exactly what we thought we would have to pay the vendor to do in their product. We need to get this into the test environment in order to see it interact enough in some real world scenarios in order to make the call on using it or go back to the original expensive vendor option. We don’t have enough data and integrated systems in the dev environment to really determine if this is gonna work. How can we avoid all the testing and validation steps that the SDLC says the testing team needs before giving the green light to install this for us to use in Test?”

Project Manager = “Well, because of all the production problems recently, those testing steps we used to be able to get a pass on are now absolutely enforced. I haven’t heard of anyone in the last month getting a pass to skip a single step.”

Joe Project Technical Lead = “We don’t have two months to go through all the rounds of testing of a new component just to find out it is crap.”

Project Manager = “Ok, I have a plan.”

Joe Project Technical Lead = “I’m all ears.”

Project Manager = “Have Bob ask Judy in Operations to open a trouble ticket on the Flim-Flam app. Have Bob give you the trouble ticket number he gets from Judy. Then you call Tim in the support team and let him know you have a patch for that trouble ticket. If we call it a patch not a new component, Tim’s team can install it in the Test environment as a ‘production defect resolution’. Have Bob install it in Dev, write up the patch install documentation and attach that doc to the trouble ticket resolution section. Once Bob has done that, you can call Tim and ask for a resource from his team to install the patch indicating the docs are attached to the ticket. If I call, it will look like the project is making the request. If you call, it is Development providing a defect fix. Then have Bob go through the emergency development access process to the Test environment after Tim’s resource has updated the trouble ticket with a patch installed status. Bob can do whatever testing you think you need to make the call if it is gonna work or not.”

Joe Project Technical Lead = “Do you think Judy is going to go along with this plan? In order to back all this out, she is going to have to call back in and say the trouble ticket can be closed because the defect wasn’t an actual defect.”

Project Manager = “Yes, I’ve worked with Judy before. Plus, her team benefits from some of the new functionality delivered in this project phase, so she has a vested interest in helping us push this forward. Plus, Tim is under pressure to show progress in trouble ticket closure metrics, thus he is going to want to get an offshore resource engaged to close this new ticket quickly.”

Joe Project Technical Lead = “Ok. I’ll grab Bob and fill him in on the plan.”

A project manager that just reiterates the formal process maybe doing their job, but a project manager that knows how to translate a project goal, in this example, additional hands-on confidence in a change to the project solution, brings real project management value to the project team.

3. Attention to detail and follow through

In trying to narrow down to three strong project management attributes a project manager needs to have to excel at project management in a large IT shop, having a strong attention to detail and follow through may seem, again, table stakes for all project managers. In my experience, there is a constant state of noise surrounding a corporate IT project that needs constant squelching. In contrast, short running projects, of which there are very few in large shops, can usual squeak by with minimal outside interference. That minimal interference can usually be addressed by an average project manager. Projects that run many months or years don’t have that luxury.

For long running projects, it is absolutely critical for the project manager to be completely on top of all the noise and know who to engage to ensure the noise can be ignored or if the noise represents a material impact to the project. One example of noise is a newly proposed enterprise component that everyone needs to use that, on the surface, sounds like a critical path item for the project team, in reality, has no funding support and no project toll gate or review that will enforce its use. Such noise, once determined to be true noise, needs to be cast out of scope to keep the project resources focused on delivery as quickly as possible. An example of noise that can’t be ignored might be a new project funding review activity that has enough executive support to warrant proactive insertion of the project into the review pipeline ASAP to ensure smooth sailing through the new process. Ignoring such noise results in the discovery, down the road, of a roadblock when the project is at a critical milestone. Scrambling resources in a finance “fire drill” activity late in the project is obviously inefficient. Calls of “How come we didn’t know about this sooner? Does this put the delivery date in jeopardy?” from the project sponsor cast considerable doubt on the effectiveness of the project manager.

Thus, seemingly table stakes for a project manager to be attentive to details, the larger the project the more the need for a project manager to be vetting out details and sorting out noise from real project activities. Project managers that have the skills and intra-company relationships to quick vet the noise and squelch or engage efficiently excel at delivering projects on time, on budget and without undue stress on the project team.

P.S. This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Seventy four (74!) bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Netherlands, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labor is now (literally NOW) available all over the web. The complete list of all participating blogs is found here so please go and check them out!

, , ,

Are Corporate IT Patents the on the Rise?

Are Corporate IT Patents the on the Rise?

Many times in the course of a corporate IT project, new and innovative technical solutions to challenging problems are developed. Many of these solutions are related to the hoops one has to jump through to get company specific legacy systems and legacy decisions to integrate with new technical products or capabilities. Thus, are these solutions truly innovative? No, most are not if they are viewed in the context of “from outside the company”. “Inside the company”, they could be a miracle of cross-team, cross-department partnering and vendor product limitation mash-ups. “Outside the company” observers would be wondering why such a convoluted approach was needed for a seemingly simple interoperability challenge. Yet, every once in a while, a technical approach to solve a problem that isn’t truly unique to that company occurs.

Geez, IT is so mature these days one has to wonder why there aren’t fifteen vendors clamoring to demonstrate how they can solve these problems with their products. The vendor landscape either hasn’t recognized that their customer base has a problem they can sell a solution for or the problem is created by vendor solutions that provide a core capability but don’t go the last ten feet to cross the finish-line of a fully mature feature set. With all this being said, the question that seems to be coming up more and more is:

Is that innovative corporate IT technical solution worth getting patented?

My first thought that always comes to my mind in these discussions is:

Why is it worth it to patent something corporate IT-ish when the business’s core competency isn’t delivering IT products and services?

It is easy to understand why, say, Apple, Google and other tech companies are rushing to patent new and innovative techniques such as in the mobile device functionality space. The monetary compensation surrounding having to pay a competitor licensing fees means you win, revenue-wise, when your competitor sells a large number of devices. Imagine if you were the patent holder of something used in the Apple iPad 2. If you licensed that invention to Apple for a mere one cent per device, in the fourth quarter of 2011 alone, you would net $154,000.

Thus, it seems that corporate IT does not get to generate direct revenue through patenting solutions. So why do so? The strategy here appears to be one of investing in a solid defense as opposed to an aggressive offense. That defense appears to be at least two fold.

Vendor Leverage Reduction

Vendor products are so pervasive in corporate IT it is next to impossible to avoid the sometimes painful contract negotiations. I’ve written quite a bit about the corporate IT management/vendor relationship in the past in a series starting here. If a vendor becomes aware you are using your own approach to a solution they have patented, the company can lose significant leverage in the contract negotiations as the raw legal sparing can trump the best sales/customer relationship. These negotiations can turn even worse if the company is trying to switch to a competing vendor.

Non-IT Company Product Battles with Competitors\

More similar to the classic tech company patent wars such as between Apple and Google/Motorola, non-IT based companies have similar legal battles over non-technology product patent infringements. In addition to holding the non-IT patent, having an additional IT-centric patent that complements the original product patent infringement helps strengthen the case of that patent holder. Thus, not a clear cut win for the patent holder, but clearly a legal strategy to make the claimant have to invest in an even larger, more expensive and time consuming case.

So, can everyone expect a rush to apply for patents for innovative corporate IT solutions in non-IT centric companies? I wouldn’t say rush, but as technology become an ever more important and strategic component of traditionally non-IT centric companies, look for a steady increase in patent applications as part of a holistic business strategy to be in a strong position to go head to head with a competitor in a patent infringement suit.

, ,

Today's IT Projects Need Transparency to Change

Today's IT Projects Need Transparency to Change

For large organizations it seems that as technology grows more and more integrated, IT related projects become more complex and thus longer in overall duration. There is no doubt the rise in cloud/SaaS solutions has exacerbated this increase in overall IT project complexity. I’ve written on the impact of cloud in this manner prior here. Gone are the days of a large corporate IT shop having a project manager engage the same three or four familiar delivery stakeholders and with little outside involvement, execute the project beginning to end. This increase in technical integration means a project manager can no longer count on those three or four stakeholders having the cross systems knowledge and technical systems access to implement changes as crisply with few artifacts as to what the project has done/is doing/when/etc.

To help illustrate this evolving shift, consider the following hypothetical large corporate IT conversation:

PM: “Welcome everyone to the FlimFlam upgrade project’s twentieth weekly status meeting and a special welcome to Jim who is joining to help sort out all the changes that impact others outside of our core team.”

<General welcoming gestures and verbal niceties ensue>

Jim: “Ok, is there any diagram that captures all the flows of data in and out of the current FlimFlam system?”

Core Team: “Um, no, we just know them from working on FlimFlam for the last five years.”

Jim: “Um, ok, have you mapped out what new features of the upgrade are turned on compared to off and who would be affected? Or say, documented the link between the features and business requirements?”

Core Team: “Well, not documented, but we know HR wants the real-time instead of batch interaction and Operations wants better reports. But HR outsourced last year to a cloud provider and we have no idea what Operations is doing …”

Jim: <thinking to himself> “… oh boy, good people, but this project is looking like a train wreck already …”

Clearly a “business as usual” approach to this upgrade isn’t going to work any more.

In the past, with so few stakeholders having comprehensive access to the silo-ed systems impacted by these types of changes, the need for easy to digest transparency into what changes were going to happen when and how was not critical. Sometimes the only visibility to what such a small project team was doing was in the production change management review and approval process:

Change Control Board: “Ok, next up is change record number 72,578 which reads ‘Enable the employee web portal to support the time off calendar’. Anyone here have any concerns with this change? Hearing none, approved. Next on the list …

Today’s Problem: IT systems are too interconnected for lack of project transparency to change

Sounds like 72,578 is a simple change that an HR delivery team of the past could have easily implemented without much cross team impact. But today, that example time off calendar may need to interact with the HR system to record those time off days against how many the employee actually has as part of their compensation package. There probably is a need to support some management approval work-flow. Plus, there are probably other work scheduling systems and PMO resource planning tools that need a feed of that data in order to accurately support their user base. There is probably some single sign on/web access management technology involved to support all employees accessing the web portal, some central provisioning system to handle access plus some remote access needs to support today’s mobile workforce. It is probably safe to assume that some of those integrated systems are in-house and some are cloud/SaaS or a mix of all of the above.

Additionally, with matrix-ed internal and external project resources with contracted and off-shore delivery coupled with the “cloud” vendor resource engagement model, a simple change could have a variety of stakeholders in need of agreement on what is changing when, etc.

Thus, hopefully I’ve convinced you that something as simple as a web portal for employee time off entry can involve a number of different internal and external teams and systems that all need to coordinate changes to support the business objectives of this example project.

So how does this all drive the need for “transparency”? Isn’t this just a basic PMO 101 issue of dependency management and cross project impacts?

Yes and No

The project team needs to produce deliverables that don’t just get the core team in agreement to pass the next quality gate in the project life-cycle (never to be revised again); the project team needs to produce deliverables that outline, at a high-level, the following basic project elements:

  • Scope of the project in a sentence or two
  • What is changing from present to future state
  • Who is impacted by the change (and have they been engaged)
  • Lastly, what isn’t in scope (that a non-core stakeholder might assume is in scope)

… for non-core stakeholders to easily digest and understand … and update the material frequently to have at the ready anytime it might be needed.

Besides an effective communications vehicle, another subtle yet important aspect to this deliverable is its ability to build confidence in the effective management of your project in outside stakeholders. This confidence can lead to senior management getting the impression the project is “under control” and move on to another project for increased scrutiny rather than assigning all kinds of ancillary people to dig into your project to figure out why they don’t have that “under control” feeling.

Stated another way, large corporate IT projects today need to adopt a bit of “program management”, specifically, some of the enterprise reporting themes. A Gantt chart (which I’ve extolled the benefits of before here) isn’t the end-all-be-all here. A slide deck that contains a few slides covering these topics with lots of pictures and drawings where ever possible would be more effective in serving this communication need.

So if you are a project sponsor or a project manager, consider having a communication deliverable that is actively maintained, even if your PMO PLC doesn’t explicitly call for one, to provide simple and easy to digest transparency into key aspects of your project at the ready at all

, , , , , , , ,

Produce a Business Case Deliverable

Produce a Business Case Deliverable

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

In the second part of this series, we used an example of engineer Bob recommending his company invest some cash and resources into an operating system upgrade. The initial logical conclusion that a sequence of facts surrounding how awesomely technically cool the new OS is would convince anyone to make the investment. Yet, spewing facts isn’t as compelling as it is to:

Relate the facts and figures to senior management’s goals/vision

To do this, structure a presentation into a story following this sequence:

  1. Describe the Current State including gaps/challenges/issues/problems
  2. Describe the “Optimum” Future State
  3. Describe the Roadmap to get from Current to Future State
  4. Outline the immediate next steps to get started on the Roadmap
  5. Throw anything ancillary or supporting to the above 4 steps in Appendices

In the Bob’s case, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Using the above sequence as a template for Bob:

1. Current State

  • Number of servers running prior OS, server count over time
  • CPU utilization
  • Maintenance costs (total cost of ownership if it can be computed, support contract costs)
  • Indicators when “bad news” like special support contract costs, etc. show “doing nothing” is a negative
  • Intersection with any other projects that need capabilities provided by your Future State

2. Future State

  • All servers running new OS phased in over timeliness
  • CPU utilization
  • Maintenance costs

3. Roadmap

  • Upgrades broken into simple chunks
  • Chunks representing some useful grouping (rather than random)
  • Testing or other functions supporting the upgrade
  • Costs over the duration

4. Next Steps

  • $$$ approved to buy hardware
  • $$$ approved for 2 resources
  • Initial steps within your organization to get a formal project going

5. Appendices

  • Data showing why 2 resources are needed, what happens if you get 1 or zero or 12
  • Any other data, facts, figures around “hot button” issues that might come up like a trend to out-source or in-source work, strategic vendor partnerships, etc.

Your goal in telling this story is to have a compelling deliverable in the form of your presentation that conveys to anyone that it would be just plain silly not to execute your roadmap. That “anyone” needs to be both technical and non-technical people. I am certain your technical peers are going to be 110% behind anything that involves implementing new, cool technology. What techie holds the position of “nah, I still want to be a Windows 98 shop.” At the same time, the more holes that can be poked in your analysis the more likely your great idea is going to get trampled by the masses and not acted upon.

Sure, others might suggest not putting this much effort into a request that “should just stand on it’s own to support action”. A recent (how timely!) tweet from @rands suggests as such:

And although it might seem highly desirable to be able to convey your technical request in words and have immediate understanding and support, those veterans of large corporate IT shops know there is a big complex organization with overlapping, competing and sometimes contradicting priorities that can easily mount a campaign against your plan. Thus, those quick to dismiss the value of a slide deck deliverable in corporate IT might be missing a critical element of this series: producing a deliverable.

Sure, once you have a deliverable out there others can still mount a defensive. But, you also empower your management with a strong case to move in your direction that can be forwarded along and forwarded up. The more compelling your story, the more it stands on its own as a viable business case to make a strategic company investment the more the financial/business minded in IT will be able to comprehend and support your plan.

So, before you write-off the value of putting the effort into crafting a story deliverable that compels the non-technical decision makers to act on your plan, consider the alternative: a verbal request to spend money on some cool technology? If you are planning to invest a significant portion of your own money, do you want to buy some cool technology or act on a strategic technology investment with data backed returns?

, , , , , , , , , , , , , , , , ,

Convincing senior management of technical direction requires new communications skills

Convincing senior management of technical direction requires new communications skills

As a server administrator, you invested in knowledge associated with configuring operating systems to perform optimally and be able to interrogate error logs to diagnose and report problems efficiently. As a software developer, you sought feedback from code reviews and combed forums and blog posts and (depending on when you were in this role) books to improve your code. In your role, you invested in the technical skills that expanded your ability to deliver solutions within your respective discipline.

Being measured on skill-set attainment wasn’t particularly evasive. Your servers were deployed live and they either performed their needed functions in support of applications and end users or they crashed after deployment with a flurry of functional issues reported to the helpdesk. Your code either met the functional requirements and was bug free after being tested or defect reports mounted. There was more direct feedback as to what skill-sets you have mastered and what areas of your respective discipline needed more investment.

Even communicating to your direct manager in these technical roles provided more instant feedback as to your ability to successfully articulate problems, issues and recommendations for improvements due to the frequent interactions between yourself and your manager. And from your manager’s perspective, they were tasked with delivering a service and needed you to execute tasks to meet commitments.

But what about communicating to senior management?

In most cases, you are not directly interacting with senior management on a daily or even frequent enough basis to build implicit trust. You can rarely walk blindly into a budget meeting with senior management and say:

“We need to upgrade all the servers to RHEL 6. In order to do that we will need to buy ten new servers at X dollars each for a total of Y dollars now and we will need two more people to build and swap in all those servers. Of course, we’ll need all the applications to test after each server is re-built. And …”

with senior management responding with:

“Sure Bob, let me get out the checkbook …”

It is almost painful to observe a solid, technical individual attempt to explain a technology need to senior management who hasn’t determined how to effectively communicate that need in a format that senior management can more readily absorb. Equally troubling is seeing a poorly communicated yet real technical need be decided against by senior management based on a weak presentation. You can almost predict the conversation that will happen some number of months later:

“Bob, how come we have to pay this huge support contract on our servers? How come I didn’t know about this earlier?”

“But Sir, I tried to tell you we needed to upgrade our servers before …” This conversation becomes more awkward with each subsequent exchange.

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

So, what steps can one take to make this investment in their communication skills? For one who has focused on learning technology, the shift of focus to learning effective communication skills may seem elusive at first. Thus, consider spinning up a thread in your brain that breaks this down into a logical exercise.

Look for part 2 of this article to dive into some logical steps.

, , , , , , , , , , , ,

Project sponsor turnover can be handled smoothly

Project sponsor turnover can be handled smoothly

Hallway conversations and whispers in meetings have the grapevine quickly communicating the departure of a highly visible person in the corporation. “Did you hear Bob gave his two week notice?” “Yah, any idea where he is going?” “No, I don’t think he shared that.” “Who is going to lead the big FlimFlam upgrade project now?” “Don’t know that either. It hasn’t been announced. Bob has been it for as long as anyone can remember.” “This could get very messy.”

I was reflecting on my participation in a large, multi-track, multi-phase, multi-year project some time ago. So, safe to say, this was a big project involving substantial change across a variety of technology groups, products and business units. About a third of the way through the project, the day to day business sponsor left the organization for an outside opportunity. Since the project was well under way, being a third completed, a new sponsor was needed to step in quickly to keep providing direction to all the concurrent work streams.

Executive Leadership Steps In

The executive sponsor immediately started attending the regular program level status meetings. This provided much needed leadership. Thus, two big thumbs up for her participation. Instead of everyone looking around the table at each other wondering who was in charge, there was continuity in project leadership.

New Sponsor Arrives

The executive sponsor didn’t waste much time sourcing a new business sponsor for the project. With only a few weeks of drift, a new day to day sponsor was at the table. The executive sponsor gave a brief introduction and the new sponsor took charge. Following the introduction, it was clear to everyone that the new sponsor wasted no time getting up to speed even though he had no prior knowledge of the project nor subject matter expertise in the goals and objects of the project itself. The new sponsor already had had meetings with key stakeholders individually.

New Sponsor Sets the Tone

The new sponsor also gave brief summary of the current state of the project, the major open issues and summarized the strategic next steps. In summarizing the next steps, the new sponsor established an immediate credibility as the prior sponsor seemed to be struggling a bit with how to prioritize the cross-functional team’s focus for the in-flight work streams. All in all, the new sponsor, in the first formal meeting, established a strong confidence that had everyone leaving that meeting with a positive sense of enthusiasm that we were all in good hands for the remaining work ahead. The new sponsor clearly set the tone for project success.

So what made this potentially negative situation result in a re-energizer to the project team?

  • Executive leadership presence immediately upon word the current sponsor was leaving the organization.
  • Executive leadership remaining visible and actively engaged through naming the new sponsor.
  • The new sponsor’s strong initial engagement and clear understanding of:
    • Project’s current state
    • Clarity surrounding open issues
    • Ability to articulate next steps.

Has anyone else experienced a positive project sponsor change? What contributed to the success of the leadership switch?

, , , , , ,

How do you survive without SMART goals in today's Corporate IT?

How do you survive without SMART goals in today's Corporate IT?

There are plenty of great resources on the Internet that offer excellent perspectives on management and leadership that can be readily applied to those working in corporate IT. And one would think with the vast amount of excellent free advice, all managers would excel at their jobs. Alas, today the demands on IT management make readily putting that advice into practice exceedingly challenging. Recently I’ve been contemplating on how to best articulate what I feel is the dichotomous role a corporate IT professional has in today’s workplace.

Dichotomous Role:

  1. Deliver on what your manager of the moment expects
  2. Deliver on what your role is expected to deliver to the organization

Why “dichotomous”? More often than not, what your manager expects can be incongruent with what the organization expects.

One might think all you have to do is understand your job description, your department/team/personal goals and objectives and go off every day and do your job. And for some they maybe enjoying this straight forward, obvious job function clarity. But for most, I would feel confident in saying that seeking this expectation clarity can consume a significant number of brain cycles everyday with varying degrees of success. Frequently, your manager’s expectations differ with what the organization expects. What forces are at play creating this dichotomy and what can you do to stay sane over time?

Biggest Contributors to Role Dichotomy? Lagging Goals + Manager Shuffling

First, Lagging Goals

I know of no study or statistical evidence to support my claim, but I feel rather confident in saying that the rate of change in IT has increased dramatically in recent compared to prior years. Step back and take a sample of recent IT management articles. How many are asking the CIO role to change? How many are saying you have to have a mobile work force, outsource development or leverage “the cloud” or risk falling behind? With all that rapid change, in my opinion, pragmatically, gone are the days of SMART goals. Recently, Pawel Bordzinski posted an article similarly calling SMART goals into question here. Sure, MBA academics and management blog pundits will tout the benefits of clearly articulated goals leading to reports having increased delivery success and improved job satisfaction.

Let me be clear up front; I am not contradicting the sound fundamentals of solid goal setting. But unfortunately, with corporate fiscal cycles starting/ending and thus “trickle down” goals trailing six months or more from the cycle start, the average corporate IT employee is lucky to get written goals if they get any goals at all. In looking back over my last five years I probably can point to only two situations where I actually was given documented goals for my job role. In both cases, the fiscal year had already been underway for a good five or six months before I got those written goals.

Why the lag in goal delivery when all sound management principles suggest timeliness equals improved organizational success? In a phrase:

The current corporate business climate expects IT change at such a rapid rate that lagging goals can’t easily, if at all, keep up with the organizational change and subsequent overlapping vision changes.

These typical corporate IT scenarios may seem extremely similar to many and they help illustrate my point. Consider how established goals would need to be handled in each case:

  1. The company hires a new “chief marketing officer” who has a new chunk of budget to spend on a “mobile strategy”. Suddenly, new IT projects are kicked off to deliver mobile solutions.
  2. An IT Director of the “something” department retires and a new Director is hired from outside the organization. Managers reporting to the previous Director either start reporting to new areas of the organization or start leaving the company. The new Director starts hiring replacement mangers from his prior company.

In the first scenario, assuming managers, teams and individuals had goals that reflected pre-CMO priorities, all now have to wind down a bit on what was previously being worked on and wind up on what the new CMO sponsored projects entail. Sticking to pre-CMO priorities are just not an option. The company clearly has a strategic gap hence the CMO was hired in the first place. Thus, ignoring the CMO’s “high priority” projects because they don’t fit nicely into prior communicated priorities and goals is effectively ignoring the business needs of the company.

In typical corporate IT fashion, the priority of these new CMO projects has been communicated from the top of the house down thus the entire IT delivery management structure is trying to figure out how to reshuffle in-flight work in order to accommodate them. The crisis of the moment has shifted from whatever was the previous crisis to the new CMO project delivery crisis. The company wasn’t strategic enough to see the need for a CMO earlier as new media outlets were creating new demand, what is to say the organization is strategic in addressing new IT project priorities? Lastly, with IT departments cut staff and budget-wise due to the recent recession, what management structure is going to stop and revise all previously documented goals? The demand for flexibility, agility and rapid change makes it next to impossible to be able to cleanly re-write goals as priorities shift.

If the goal setting challenge faced a stagnant organizational chart, then there might be some HR efficiencies all could leverage, but on top of priorities changing, org structures rarely stay static for more than a few months. The second part of this article will dive into what compounds the goal problem for corporate IT employees: rapid organization and management reporting structure changes.

, , , , , , , , , ,

Earlier this week I was given the opportunity to share my “aha moment” when it comes to project management.  Below is a brief quote from my article submission:

“Like it or not, technical people need project managers. Yet, ask the average software developer, systems integration engineer or infrastructure engineer about what their company needs more of role-wise and they will almost without a doubt say: “We need more X’s. I’m buried in work!” Feel free to replace “X” with whatever job title applies to whom you are questioning. Software developers indicate they need more developers because the product owners keep asking for more features faster than can be developed.”

Feel free to read the article in its entirety here.

, , ,

"I just signed the sales contract yesterday. This needs to be up and running by the end of this week!"

"I just signed the sales contract yesterday. This needs to be up and running by the end of this week!"

In talking to others recently, we’ve discovered an unfortunate pattern across multiple companies where the partnership between the business units and IT isn’t particularly strong. When I say “partnership” I mean the level of collaboration on business activities that involve IT in some manner. Prior to contracts being signed, has IT been directly involved in the new business opportunity? Does IT have a voice in the major initiative delivery date setting process? Is IT’s resource capacity considered at the same time the business’s resource capacity is being evaluated in moving forward with a major effort? Does IT have access to the business’s multi-year plan? Are IT initiatives peppered throughout that multi-year plan?

There are a seemingly endless list of articles available on the Internet that talk of the need for a strong partnership between IT and the business units IT supports thus I won’t extol those benefits here. Rather, what can an IT manager do in a company that is taking strides towards but is still working on forming a strong business and IT partnership? Or …

What to do when the Business wants “Instant IT Gratification”?

By “Instant IT Gratification” I mean the corporate culture where IT is expected to delivery what the business is asking for, how they are asking for it and when they want it done all without collaborative dialog. Contracts are signed without IT. Due dates are determined in advance and IT is expected to meet these deadlines without being consulted. The results of such interactions between IT and business requesters varies, but the thematic results are the most frustrating:

  • Sub-optimal technology implemented: Instead of matching the need with the optimal technology, the quickest/fastest must be chosen to hit the date.
  • Many post-deployment follow-up activities needed: Instead of having a healthy collaborative discussion about all the “requirements”, only what the business shares is implemented requiring many “oops, we forgot we also need X”
  • Inability to upgrade/enhance existing technical capabilities: always focusing on the urgent needs of the business without allocating a percentage of time to invest in more current technology assets.
  • Work never done: Constantly jumping to the next hot request leaving only phase one of Y implemented from the previous hot, now cooling request.

What can an IT manager do in this kind of culture?

Anyone who skimmed the above bullets and identified with even one point knows these are cultural problems that a single IT manager won’t be able to solve over night. So how does one not pull their proverbial hair out of their head trying to get anything proactive accomplished in such a re-active business model? Consider some of the options below; just know that none is a silver bullet of success.

  • Leverage the formal charge back model.

If your organization has a formal IT work charge back model, become intimately familiar with how the process formally and informally works. Employ the charge back model in every possible situation to ensure there is fully accountability and record-ability for all business requested IT work.

  • No formal charge back model, then use time as the “IT currency”.

If no formal charge back model exists to leverage, then the only real charge back model or IT “currency” is time. Make sure you have full data based reporting on all the work your team is performing. When a new “hot” request comes in, update your single view of the work and present the new “hot” request alongside all the previous “hot” requests and ask the business to prioritize.

  • Like it or not, get some formal work estimation model in place

If all the business requests “just get handled” then the business has no governor for making requests. Without a charge back model to where the business has to make the conscious decision to spend on one thing compared to something else, there is no barrier for the business to make every conceivable request to IT. One approach is to “just handle it” and try to service every request as quickly as possible so to not have to engage in any prioritization or work break down discussions. But as I have written prior, having some formal work estimation process allows for an intelligent, data and date based discussion with the business. When presented with duration and possible delivery dates, business users can more easily take low priority work off the request list. Low priority work can easily be removed once it is known by all what is consuming time and delaying the delivery of what the business truly needs in a hurry.

  • Don’t blindly start working on requests, ask probing questions

From a previous article on my learning in attending a formal Agile training class, asking why multiple times (per the instructor, ask “why?” five times to get to the bottom of the need for a request) in order to dig into the real reason for making a request for work to IT. You will be amazed how many times the request hasn’t been fully vetted by the business. Asking why to get to the real business case to support a request will help to reveal what is truly a priority that IT is in the best position to deliver on compared to a frivolous request that if not executed, actually reduces technical debt without harm to the requester. Invest 40 IT hours in order to avoid a situation that happens maybe once a year and consumes 4 hours of the business’s time? Assuming all costs being equal between the business and IT (usually IT costs more per hour) , a ten year return on investment? It would seem those 40 IT hours should be invested elsewhere.

As I said, these clearly aren’t silver bullets that eliminate the challenges of a less than strong partnership between IT and the business units. Yet, by consistently improving ones capability to work with business requesters through careful implementation of the bullet points above, one can establish a level of credibility for your team’s services back to the business to better align the limited IT resources with the highest priority work for the company as a whole.

, , , , , , , , , , , , , , , , ,