Will Lassalle, Next Great CIO

Amazon FireTV & Controller Unboxing #throughglass

Posted by Unknown on Sunday, April 06, 2014

The A-Team errrr B-Team!?

Posted by Unknown on Saturday, December 07, 2013

Outsourcing engagements need to be managed carefully and properly from the cradle to the grave. When selecting a vendor during an RFP process, you will more than likely be presented with the A-Team that will be working your account. More often than not, you will be given the companies B-Team or even C-Team. What this means is they will present you with top quality talent and resumes of the resources that "will" be working your account.

In one case an organization was presented with top tier CCIE talent to be working on the account. When the deal was signed however, they were being billed for CCIE talent but given junior level network administrators to work the account. In the end the vendor was kicked out of the company after there was numerous fraudulent activities found in addition to the bait and switch of the network engineers.

Another case, had an organization years into a contract start replacing good desktop techs with family members who needed jobs but had no technical skills. The customers suffered through declining service levels while techs were working their issues with no technical skills. The client never bothered to care or inspect the skill sets of the newly hired techs working the account. As a matter of fact, one of the criteria for any techs was that they have A+ certification, none of the family members were A+ certified.

The above two examples, are based on outsourcing agreements where there is some language in the contract on what resources will be on the account. However, Not all agreements talk about the specific resources. A large amount merely speak about the work that is to be completed and agreements on the quality and/or timeliness of this work. With these agreements you need to be extra careful to manage the outsource vendor.

In an example of an agreement which only speaks of the work to be done by the vendor for the client, the vendor disengaged a top flight systems engineer to replace him with a cheaper very junior quite incompetent administrator. The admin did not know how to configure or check on tape backups, did not know how to logon to a Barracuda firewall, did not know how to configure email on an iPad and did not know Microsoft Exchange. The organization suffered from the lowered service levels, but since no SLAs nor specifications on the qualifications of resources was included in the contract, the client got what they agreed to and paid for. The client also was a non-profit that qualified for donated software including Office 365 for free, but instead had to suffer for too long on a poorly set up Exchange 2003 without SSL security.

The above is to illustrate that when outsourcing a business function, close attention needs to be given to the actual resources (people) that will complete the work. Whenever possible, make sure the contract is written in a way that protects you from less than expected resources ruining your customers experiences.

Attack of the Governance Monster!!

Posted by Unknown on Monday, October 14, 2013 in CIO, IT, lessons learned, Management, pmo

Governance is the act of governing. It relates to decisions that define expectations, grant power, or verify performance. It consists of either a separate process or part of decision-making or leadership processes.

A Project Management Office, abbreviated to PMO, is a group or department within a business, agency or enterprise that defines and maintains standards for project management within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution.

Governance has its place in Project Management Offices, however when the governance person or group within the PMO becomes a monster, governance impedes successful delivery of projects which is what Project Management is truly all about.

An organization I did some work for had a governance organization within the larger PMO whose job was to do as described in the two definitions above for Governance and PMO. However, the larger message was missed which is successful project delivery/execution.

Too many projects would suffer from QA of documentation with Project Managers not getting help to complete the documentation which would not provide any value to the delivery of the project. Let that sink in.

Documentation for the sake of documentation to justify weak project managers existence as they provide governance and tell you how YOU should manage the project, while they sit at their desk creating documentation and processes without any input from the actual Project Managers and Program Managers doing the execution of these projects.

One individual in particular in this governance organization of the PMO, in the spirit of October and Halloween lets call him Ichabod Craine although in this story instead of being Headless he’s actually Brainless, would present challenges to projects that would inundate PMs and provide absolutely NO VALUE. He would recommend that projects be done Agile when they had nothing in scope that would warrant or take advantage of being done Agile. He would perform QA spot checks and ask for documentation to be created that had no reason being created for that individual project just because it is listed in the processes the PMO created. The same processes they created and claim are one size fits all projects when in actuality they don’t.

Governance and a PMO should provide value to projects. That is they should help the projects to deliver successfully and the use of resources on the project achieve the results originally intended. When the evil Governance Monster rears its head and provides no value to the project and in fact impedes successful delivery of projects, this is when you have failed and need to blow the PMO up.

Or at the very least eliminate the useless individuals within the governance organization that are not providing value, not soliciting the input from the actual Project Managers doing the work and basically sitting around collecting checks at the expense of the successful delivery of the project portfolio.

Governance serves its purpose, but when it provides no value to the PMO or IT organization as a whole its time to destroy and rebuild. After all who is policing the police?