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

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.

Building structure without command and control ... isn't that an oxymoron?

I can’t say enough positive things about the stimulating agile management views shared in Jurgen Appelo’s new Management 3.0:Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn)) book currently available here on Amazon.  Jurgen has assembled an extremely thought provoking text that covers the breath of the challenges to effective team management today.  From the basics of self-organization to leading people to effective communication to competing management models, Jurgen has provided chapter after chapter of excellent insight into what is needed to manage in today’s dynamic business climate.  Even though I could go on and on about my interpretation of each chapter, this article will focus on one aspect of Jurgen’s “Martie the management model” depicted in the below graphic and introduced in Chapter 16 labeled “grow structure”.

Even though my background is focused on working in corporate IT departments rather than tech startups or consulting, I found great validity in Jurgen’s “views” outlined in his management model including his own admission that it is “wrong” (p.371) to some degree as all models are inherently wrong in being comprehensive and time proven.  Some may say that corporate IT and in particular, large corporate IT departments are unable to be “agile” and thus such an agile management model is less relevant.  I disagree in that there is a constant barrage of blog articles and news stories pressuring corporate IT to be more nimble, deliver more value quicker and with less people.  Thus, managing less people who are expected to wear even more role and functional “hats” requires a more progressive management style compared to the more traditional command and control approach.

With all that being said, wouldn’t one conclude that to “grow structure” one would have to invest in even more command and control management techniques?  Quite the opposite is proposed in Jurgen’s model.  Covered in depth in chapter 13, Jurgen suggests that in order to be in a position to efficiently adjust to the changing demands of the overall organization, technology, products and people, a manager must institute concepts he identifies as “generalizing specialists, wide job titles and informal leadership” as summarized on page 309.  I interpret, from a corporate IT perspective, the structure he is proposing to be one of recognizing the multiple hats and positioning the team to best adapt to change.  Examples in my mind include working with that technical expert in one narrowly defined domain to assist them in appreciating the need for expanding outside of their discrete technical silo through coaching, mentoring and stretch assignments.  Additionally, challenging team members that have been previously placed in narrow job definitions to think of delivering more expansively; while at the same time, providing some structure to that expansiveness in order to provide a level of focus so team members can actual accomplish a task or function.

So, implement wide job titles, push team members to take the lead on assignments (informal leadership) and stretch specialists to become generalists … this doesn’t sound like creating structure?  I encourage you to pick up a copy of Jurgen’s book and explore how he eloquently presents a compelling argument for why such destruction of traditional command and control management is most effective in being an effective manager and leader in today’s business climate.

Is everyone at the same level of competency?

As I was trolling through my RSS feeds of blogs I try and keep current on and I ran across another thought provoking post by Todd (@backfromred) entitled “The Failure in Gating Process”. I wrote a brief comment to share with Todd and his readers. In the comment I stated that I both agreed and disagreed with Todd’s premise. This blog article expands on that conflict.

Todd’s premise is that having PMO enforced project gates:

• Interrupt project progress momentum
• Allow management and sponsorship stakeholders an excuse to zone till “quality gate #4 next month” before paying attention to the project
• Efficiencies lost to stop, starting and context switching

It is difficult to argue that gating process or projects does have a “cost” associated with the stoppage.

Todd’s solution is better stakeholder engagement.

Again, I can’t disagree with his solution in theory. Where is disagree is in the practical implementation of “better stakeholder engagement” in the real world. First, project teams need strong, competent and knowledgeable participation from these disciplines:

• Project and Executive Sponsorship and Prioritization
• Project and Program Management
• Enterprise and Application Architectural Alignment
• Requirements Gathering, Documenting and Tracking
• Business/Systems Analysis
• Vendor Management (if 3^rd party providers involved in solution delivery)
• Technical Development/Integration Leadership/Delivery
• Testing (from unit through final business acceptance)

Simply having resources “engaged” from these disciplines does equal success if the engaged resources lack competency in their discipline and/or knowledge in their discipline to bring into the project fold.

How practical is it to have strong, competent and knowledgeable resources on every IT project in your portfolio?

I argue it is rare and even if all those resources exist in the same organization, they are assigned to the highest priority and visible project(s) alone. This leaves mid to low priority projects with a less than optimal resource mix.

How do you get timely visibility into when a less than optimal resource mix staffed project team is trending off the optimal trajectory?

You need a project gating system applied to specific projects to strategically pause, evaluate and course correct those specific projects.

I chose the previous statement’s phrasing carefully and specifically to avoid claiming that having a default project gating system as a “silver bullet”1 is the answer. Again, I’m not arguing against Todd’s claim that better stakeholder engagement is needed for successful IT projects. I’m saying the practical application in the real world still requires a project quality gating system due to the inability to have strong, competent and knowledgeable resource.

I have some thoughts on attributes of a more efficient project quality gating system, but I think I’ll need another article to collect and share these thoughts bouncing around in my head.

1. Top notch blog publisher Peter Kretzman on his blog “CTO/CIO Perspectives” has an excellent article on IT “silver bullets” and how to get early indications of projects in jeopardy.

How to marry the classic IT budget and Agile?

I’ve been reading more and more about managing large projects with Agile.  I am wondering how best to optimize the merger of the classic IT yearly budget cycle for large scale projects with the Agile principles and agile project delivery.  There has to be a way to balance the constraints of an upfront budget process with the benefits of agile-ly deployed business prioritized deliverables.  Or in other words, how does one keep the dollars and cents focused people happy and the business project sponsors enjoying the benefits of Agile delivery?

The classic IT yearly budget cycle I’m referring to is one of wild guesses at capital such as servers or software licenses, maintenance, expense and internal plus external resource costs to complete projects that involve IT in the next yearly financial calendar.  Projects maybe completely IT driven with IT as the end customer or projects maybe requested by the business to deliver business value that need IT support in delivering that value.  In either case, the classic budgeting versus agility challenges is the same.  Take the typical project mixing IT and business changes:

New Project Request Form:

Project: A456 Enable Call Center Order Confirmation

Scope: Upgrade the FlimFlam call center system from 5.0 to 6.0 to enable the customer communication widget and change the call center workflow to use the widget and not carrier pigeon to confirm orders with customers.

Budget Questions:

• How much does the upgrade cost?  (easy, ask software vendor)
• How many consulting hours and dollars are needed to support upgrade? (medium, ask software vendor’s professional services for a typical customer upgrade number, then add fudge factors to map over to your company)
• How many hours from your internal shared IT resources to support the entire effort? (hard, don’t have the time to go through the project requirements gathering and design phase or collect all stories, get story points, etc., etc., so take a wild guess based on past projects or other similar work, add fudge factors, add more fudge factors, then double it … you get the idea)

Project Budget Submission Criteria:

? = Capital

? = Maintenance

? = Expense

? = Internal Resource Hours

? = External Resources Hours

? = External Resources Hourly Rate

? = Total External Labor Costs

The budget process demands a number to be provided for each question mark.  You know that certain magic number thresholds, if cross, will doom your project or almost as bad, push it into a category that requires a whole new level of business case and ROI sizing effort. This classic IT project budgeting process doesn’t seem to support the majority of the Agile project delivery process.

Does anyone have any experience or references to best practices in this area of marring legacy budgeting and agility?

Integration going South? Time to call the Vendor Sales Cheese!

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

1. Vendor Service Integration Challenges

In the previous article, I suggested some approaches to consider as the project is underway to integrate the vendor’s service with you and your team’s technology service.  This article will explore considerations once you are in the throws of integration.

So, you have your prototyping working to reduce the unknowns associated with how to get the two disparate technologies functionally working together.  You also have your “spaghetti infrastructure” in place to reduce the risk of negative impacts to your service’s ability to continue to perform for existing needs as well as supporting the new vendor integration.  Finally, you have your “vendor simulator” setup to conduct various permutations of performance testing scenarios between you and your team’s service and the vendor’s service.  So what else do you need?

In parallel to all of the above rather technical risk mitigation techniques, you need an additional management tool to address adverse scenarios that will inevitably pop up randomly throughout the integration project.  The tool I am referring to is a thorough understanding of the vendor’s organizational chart.  Specifically, you are looking to identify the following roles within the vendor’s organization:

• Relationship Manager assigned to your company

This is the individual whose job it is to ensure that your company is happy at all times with the service the vendor is providing to your company.  This is an individual who you can leverage any time you believe additional support from the vendor would allow for accomplishing things more efficiently and effectively.  If things are trending poorly and you have exhausted the contacts and procedures to get support from the vendor, don’t hesitate to contact this individual.  They should react immediately to your needs, especially if you can summarize your thorough attempt to use the normal channels and your coming up proverbially empty.  On word of caution, make sure you exhaust the established parameters for vendor resource and assistance engagement.  If you call on this person at every bump in the road, you may get high touch service immediately, but you will quickly be labeled as a “hyper escalator” and your high priority requests will be interpreted as low priority.  This is indeed a balance, for if you don’t leverage this individual and things come to a head down the road, the vendor has an easy out for providing poor service:

Vendor Sales Cheese <role defined later in this article>: “I understand you are frustrated.  You do know you can contact Bob for all your customer service needs.  He is your Relationship Manager dedicated to you and from what I understand; no one reached out to Bob.  If you do contact Bob, he will make sure you are getting the needed service and support from our organization …”

Regardless of your level of credible frustration, you didn’t take advantage of the escalatory options at your disposal from the vendor:

• Senior Technical Person

This is the role you need to find quickly.  The vendor will most likely try to shield this person.  Why shield?  Well, if every customer knew how to get a hold of Senior Technical Person, they would for their every need because they get the real, direct and reliable technical answer quickly.  But like every technical organization, these roles are few and far between and worth protecting so only the most critical problems get into their hands.  This being said, you need to quickly identify this person and establish a back channel communications mechanism between your senior tech person and the vendor senior tech person.  Similar to the Relationship Manager role, this is a “don’t use unless you absolutely have too” communications route.  Make sure you coach your senior tech resource to play along with only contacting their peer at the vendor when the regular channels breakdown.  On the flip side, the vendor senior technical resource will appreciate being able to speak with a technical peer within the customer’s organization.  Just like your senior tech resource, the vendor’s equivalent will be frustrated with the problems that are beneath them to solve crossing their desk.  They will find it refreshing to speak with someone who shares their priority attributed to technical excellence and will provide top notch support when engaged as such.  This back channel communication mechanism can be exceedingly valuable when milestone dates are looming and confounding technical problems block forward progress.

• Vendor Project Manager

Assuming the integration effort is of a scale that involves more than a few humans completing a few tasks to integrate technologies, there will most likely be a project manager within your organization (see other series of articles on interacting within your project management framework for IT Engineers and IT Managers ).  On the vendor side, they will most likely have a Vendor Project Manager role. This role keeps the vendor resource moving forward within the vendor’s organization in parallel with your organization’s project manager.  Don’t be quick to conclude that your company’s project manager will work effectively with their peer within the vendor’s organization.  It is best to assume your project manager will fail to grasp the nuances of the technical tasks and dependencies and thus fail to get critical information passed back and forth between the two organizations successfully.  I am not suggesting you need to absorb the project management function within yourself or your team, rather, develop a communication approach that takes this miscommunication potential into account.  For example, consider adding the Vendor Project Manager as a carbon copy to all emails that make even the slightest reference to questions, answers, tasks or dependencies that involve the vendor.  For example, pass on mentioning that Bob on your team needs to take the internal account access form to the access granters for Bob to get access to that new server he doesn’t have access to yet.  This doesn’t involve the vendor in the slightest.  But, if the vendor is expecting a copy of the contents of a configuration file on that new server, then by all means add the Vendor Project Manager to the cc line of the email to your company’s project manager.  Why this seemingly superfluous communication of ancillary internal access granting minutia?  The perception becomes more clear that the vendor is waiting on the configuration file snapshot, which your team needs to provide, yet clearly can’t until access is granted to Bob.  Without this documented clarity, the Vendor Project Manager can send a heated email to your project manager claiming your company is holding up the project due to not providing the configuration file.  Your project manager, under duress, may be quick to claim you and your team are the hold up within your company.  Without this example email, you have to get on the defensive, especially to the classic “surprised and confused” response from the under duress project manager:

Company Project Manager: “What?  You needed server access in order to send over the configuration file that has been holding everyone up?  I’m surprised that you needed this access and I’m confused that you didn’t tell me about needing it.  For had I known you needed this access, I would have worked to get you that access ASAP.  Since I didn’t know about it, I couldn’t have known that this was a barrier to progress …”

The email including letting the Vendor Project Manager know all of the dependencies in order to provide the deliverable makes it obvious the communication breakdown is outside you and your team so you survive unscathed and don’t have to invest energy in forming a tactical defense or erect proverbial blame shields.

• Vendor Sales Cheese

Similar to the Relationship Manager role, you need to identify the Vendor Sales Cheese or salesperson that stands to loose big in the compensation category if the customer gets frustrated and doesn’t close the deal for him or her to score their bonus.  Depending on the vendor, the Vendor Sales Cheese or the Relationship Manager maybe the same person.  But in the event they are different people, make sure you have a clear understanding of their roles and follow the below sequence for every vendor request, only proceeding to the next step if the prior step failed to generate expected results:

1. Normal communication route (support ticket, email to vendor support mailbox, etc.) keeping the Vendor Project Manager copied on communications
2. Vendor Project Manager directly
3. Vendor Relationship Manager
4. Vendor Sales Cheese

Lastly, knowing who within your company owns the relationship with this vendor, as described in previous articles,  is also important so when you get a sense the communications are getting more heated as you are moving from the normal communication route, past the Vendor Project Manager over to the Vendor Relationship Manager and Vendor Sales Cheese, you can bring the vendor relationship owner into the mix when their vendor is at risk of causing the integration to go off track or miss a major project milestone.  If the integration project is trending in this direction, you will want to have all of the communications documented and reflecting a logical progression through the escalation path confirming to all that you and your team took every opportunity to engage the correct resources to not be the cause of the pending failure.

Knowing the contact information for all the vendor players identified in the roles above will allow you and your team to effectively manage the communications and escalatory options between your company and the vendor’s organization.  Relying on others puts you and your team at risk for being perceived as the service provider that is holding up the integration project and diverts focus from getting the technical integration completed.  The next article will dive deeper into more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.