Posted tagged ‘Program Management’

Discovery – The Art of Finding Reliable Data

June 13, 2009

There are only two kinds of application engineers: those who say
“Data is the problem” and those who say “Data are the problem.”

The infrastructure team was provided systems discovery information from a variety of sources including internal IT, contractors and key IT support vendors. The team was delighted to see “current-state” systems information. However, the team became concerned about the accuracy of the information because key application end client information was missing. The consolidation team decided to perform first hand verification of all “current-state” data. The program manager consulted with the sr management team and hired contract systems engineers with extensive application and desktop experience to review “current-state” discovery information and verify the information. In many cases, the contract network engineer had to reverse engineer networking equipment and actual protocols to obtain an accurate “current state” data. In addition, acquiring company subject matter experts were engaged to verify and document as-built server and storage system documents. For example, reverse engineering revealed the current state network documentation did not reflect actual configurations and existing routes. In another case, another key subject matter expert identified networking equipment was owned and maintained by telecom provider Sprint instead of by the company. Additional verification revealed remote access equipment had been partially configured and was unusable. The original project had been abandoned by the IT staff short of being fully configured for operations. Application verification and reverse engineering identified software code that had been written with network third party vendor addressing and communications hard coded into the software bypassing the data file inter-exchange through the company data interexchange server.

The verified “current state” was significantly different than the “current state ” provided by vendors and staff.

Lesson learned:

There is no hard-and-fast reliable information source. That would be too easy.

Project Management Scaling

October 9, 2008

 Project Management Scale – Acquisition Integration

 

Be careful how you scale the information technology integration project management effort.  You might get it.

  

IT Infrastructure integration efforts can be brought to a standstill by excessive project management controls.

 

In one mid-size enterprise organization merger, the project management office (PMO) was often a valued change agent in the IT infrastructure conversion project effort.   However, the type of project management controls and processes applied were often over-scaled, overly complicated and more suited for large scale government programs.  If your project management team is oversized, you can expect excessive overhead costs and staff meetings driven by junior staff members adding little value to the process.  A large project management organization may offer an excellent training ground for junior staff and contract consultants however, the resulting output will often be of low quality or unusable.  The overhead administrative costs relative to the size of the acquisition may be unacceptable. 

 

By scaling the project management effort to a mid-sized acquisition, a simplified set of project controls and a smaller project management staff may be sufficient.

  

Project Management Scaling

 

The first rule of organization is to scale to fit the size of the task. 

 

For mid-sized acquisition efforts, consider limiting the project management staff to two or three key members.  Ensure the project management staff reports to the acquiring company’s program management office.  This will serve to appropriately size the integration organization to the task, provide appropriate governance and ensure alignment of the local project management teams with the acquiring company integration objectives.  

 

Trim the fat.

 

https://joetighe.wordpress.com