Interesting tidbits of information - Though cloud computing (assuming catch all for IaaS, PaaS and SaaS) feature prominently on CIO agendas, analytics (including Big Data, Visualization) are not that prominent. 
Perhaps application modernization is the support for application accessibility via mobile / tablet devices through the use of a service oriented architecture, where existing applications are can be invoked by disparate presentation layers. If that is the case, it is really the rise of SOA, though with a refreshed business case. 


Interesting tidbits of information - Though cloud computing (assuming catch all for IaaS, PaaS and SaaS) feature prominently on CIO agendas, analytics (including Big Data, Visualization) are not that prominent. 

Perhaps application modernization is the support for application accessibility via mobile / tablet devices through the use of a service oriented architecture, where existing applications are can be invoked by disparate presentation layers. If that is the case, it is really the rise of SOA, though with a refreshed business case. 

Can Processes Lead You to Delivery Failure?

Absolutely. Processes are usually created to provide effectiveness and efficiency through a predefined set of steps or activities, but failure to apply processes correctly can produce the opposite effect.

The most important aspect of any process is knowing when it’s incorrectly applied or doesn’t apply at all. This requires understanding the purpose and context which originated the process.

Take for example the process of maintaining an issue and risk log which is a key part of any large scale delivery program.  The importance is clear.  Pro-actively identifying risks provide runway to introduce mitigation strategies so risks do not become issues.  Driving down to the root cause of issues allows addressing the real problem instead of the symptoms.  But what happens when the process of creating, validating, and resolving issues & risks breaks down?

How many readers have been in weekly status meetings where the project managers raise the following as issues and risks:

  • [RISK] Current plan may cause resource contention with other projects slated to begin soon
  • [RISK] Current plan has very little schedule contingency
  • [RISK] Resource vacations may impact delivery milestones
  • [ISSUE] Requirements are taking longer than expected (raised after the deadline has passed)
  • [ISSUE] Development productivity is lower than expected; impact to schedule is being investigated

These risks are boilerplate responses which merely provide cover to the project managers if things do not go as planned.  These are good signs you need to send your project managers to training or replace them immediately.  The issues do nothing to describe why the event has occurred and therefore offers no mitigation strategies going forward, leaving the door wide open for this to continue.

Allowing this poorly driven process to continue dilutes the focus on real issues and risks, destroys the value of the weekly status meeting, wastes attendees’ time which could be spent on productive activities, and causes unnecessary swirl at the leadership level.

Meanwhile, nobody challenges the poor outcome because they are blinding following a process defined by the same folks who are executing them incorrectly. 

To put this into perspective, imagine the loss of two weeks on a 100 person program with a $1.5M monthly run rate.  You just threw away $750,000.  Ouch.

Remember, the process or methodology is rarely the problem. It’s the correct application of the process which matters and this requires people who understand when a process isn’t making sense.

Are poor processes destroying your chances of successful delivery?

Image: Sira Anamwong /

Can You Deliver and Build a Strong Home Team?

Yes, but it won’t happen without a focus on several critical prerequisites. You need capable and interested candidates, a willingness to change recruiting practices, an honest review of existing talent, and a tailored approach towards keeping employees happy and engaged.

During the implementation of a large and successful program, forward-looking clients are rightfully concerned of post-pilot delivery when support from outside help (i.e. consultants) are scheduled to hand-off the reins to the client.

Unfortunately, when deadlines get in the way, knowledge transfer and training falls to the way side.  By the time the pilot rolls around and the external resources begin the ramp down, the home team is left with a bench that isn’t ready for the next game. So how do you improve your long-term chances for delivery success?

  • Pair high potential AND driven employees with external consultants who are filling key leadership roles.  If the employee doesn’t see this as an opportunity or feels they can’t learn something new they certainly aren’t interested in getting the most out of the experience.  Find someone else.
  • Look at how recruiting/staffing is done. Your “A” players should be making ALL the recruiting decisions through interviewing and accessing fit with a trial run.  Talent naturally attracts talent and creates a positive environment posed for successful delivery.
  • Clean house quickly.  If a resource is not coming up to speed when given enough runway, swap them out quickly.  Trying to make it work when there isn’t a good fit will quickly eat into delivery time AND leave you with fewer candidates to take the reins in the future.
  • Understand what drives your employees and provide incentives which align with their goals.  Developers love to work on new and interesting technologies with others who share similar interests.  Business analysts need a career path which doesn’t involve collecting requirements for the next 5 years.  Project managers need some downtime to recharge after an aggressive delivery program.

Remember, some delivery roles may be hard to fill internally due to factors such as location, cost of living, pay scale, experience, particular skill set, etc.  Having a longer term sourcing strategy for these types of roles make sense.

Pick your internal candidates carefully.  In delivery programs, strong players tend to takeover and the weaker players just go along for the ride. Instead of learning, they just take orders, waiting for the external consultants to leave so they can return to their old ways.

Ensure employees take complete advantage of the large scale program delivery experience as these opportunities are rare and the lessons are extremely valuable. Follow these guidelines and build yourself a home team prepared for long-term success.

Image: Meawpong3405 /

Don’t Let Titles Be a Barrier to Success

Companies are built around a hierarchy of people with roles and titles, so it’s natural for folks to immediately focus on the delivery operating model and organizational chart when kicking off a large program.  Who are the Program Managers, Business Leads, Solution Architects, Project Managers, Executive Sponsors, etc?

The biggest challenge with titles is they aren’t specific enough and in some cases are used to satiate egos rather than fulfill a true need on the delivery team. The other downside is titles are up for interpretation unless responsibilities are clearly defined.  This is much easier said than done. 

Take for example, the arguably overused RACI chart which highlights roles as either Responsible, Accountable, Consulted, and Informed.  A RACI chart is only as good as the activities defined.  If key activities are not captured or too high-level, the RACI chart loses its value quickly.

Another approach is documenting roles and responsibilities with descriptions such as:

  • Manages scope, schedule, and budget
  • Works closely with the PM in planning/estimation work effort
  • Communicates issues and risks

These high-level descriptions do very little to clarify who is doing what exactly.

I’ve been a part of many client discussions where resource availability is cited as a major issue or risk to starting a project or program. In some cases its a valid concern, but in many cases the planning team is too focused on ensuring every role has a name assigned instead of understanding the need for a particular role.

My advice is understand the critical responsibilities at a detailed task level, then work backwards to determine if this requires a full-time resource or just the percentage of one. Also determine if an activity/responsibility remains constant, gradually decreases, or stops early over the course of a project or program.  This is the right level of understanding to truly define the critical dependencies required for proper planning.

If you find yourself with too many overhead roles, this may point to a larger issue with resource skills or avoidance of accountability.  If you need multiple folks to fulfill the responsibilities of what should be a single person, you may want to revisit your hiring and training practices.  There’s a reason successful delivery teams are less hierarchy-focused (i.e. flat) and more task focused (i.e. getting work done).

Remember to focus on detailed responsibilities and work backwards to key roles and titles. There is no one-size-fits-all delivery model.  Having roles without understanding the need may address hurt egos, but will weigh down your delivery team with planning and communication headaches.

The Key to Winning at Large Scale Software Delivery

An executive once asked me, “What is your biggest concern with the plan?”

I had just reviewed a multimillion dollar roadmap spanning several years, involving hundreds of resources, multiple concurrent and dependent projects, a brand new architecture, and a laundry list of business and technical constraints. The estimates were high-level guesses at best. In some cases, they were just plucked from the air based on prior experience or gut feel.

A good plan is certainly a requirement to any large effort, but it’s not the key to winning. The value of any plan is directly related to its inputs. The reality is every roadmap or program plan I’ve come across has too many assumptions and variables to be considered *final* no matter how many iterations or reviews have been done.

Time and time again, companies undertaking large initiatives focus too much on building the perfect plan:

  • Did we account for every possible activity and task?
  • Did we clearly cover the scope of every business capability?
  • Do we have the right ratio of SMEs to analysts to developers to testers?
  • Do we have enough contingency?
  • Did we allocate enough budget for X and Y?
  • Did we estimate the effort for every component both new and existing?
  • Did we account for every cross-team and cross-project dependency?
  • Did we plan for and mitigate every possible risk?
  • Did we account for every assumption, consideration, and constraint?

The list goes on and on. Why the focus on creating the perfect plan? Because leadership wants to feel confident and comfortable before moving forward or pulling the trigger on a multi-million dollar investment. The challenge is no amount of time, effort, and/or money will ensure you’ve covered every base and accounted for every possible scenario. The accuracy of a planning exercise is improved only by doing the work, learning, and applying the key findings to the next iteration of the plan. 

Assume the plan will never be perfect and the question changes to "How do I maximize my chances of success in winning at large scale delivery?"

My experience has shown the biggest factor of any large program’s success is dictated by how quickly the delivery leadership and teams can identify, respond to, and resolve unplanned challenges and situations.

Don’t doom a program to failure before it’s launched.  Build a delivery team with the capability to react quickly to the unexpected instead of trying to build the perfect plan.  If you plan for the expectation there will be unplanned events you’ll be in the best position for success regardless of how accurate your plan turns out to be.

Stay tuned for pitfalls to avoid when building a winning delivery team.