The following is an excerpt from the new book, "What Top CIOs Know: How to succeed in a world of digital transformation, cyber challenges, exponential change, and intelligent devices by creating powerful strategies for the new 3.0."
Samuel R, Bressman, in his book “Overcomplicated: Technology at the Limits of Comprehension” argues that today’s systems, from ERP’s to automotive systems, are too complicated to fully debug. For example, consider Toyota. Several years ago some of their cars experienced unintended acceleration due to one or more software glitches, resulting in fatalities. In January, 2010, Akio Toyoda, the CEO of Toyota Motors Corp., publicly apologized to customers for the company’s acceleration problem. This was no small thing.
When Toyota engineers dug into the problem, they found no single module that had significantly malfunctioned. Instead, it was the complexity of thousands of interactions that caused the bug. The company was forced to rewrite millions of lines of code so that the entire system would be better integrated and logically structured. The snake in the grass was too much layering of modern code on top of a legacy architectural platform. Anyone who has worked with legacy financial system code has experienced similar challenges. Debugging any glitch requires going back in time to the age of mainframe dinosaurs.
Project methodology—somewhere between a band aid and a cure for complexity
It is nearly impossible to implement a major system or enhancement on time and within budget without a defined methodology. A plethora of roadblocks are waiting to derail the project:
· Scope creep—adding additional features beyond the original agreed upon design and requirements
· Technology creep—implementing a new platform, language, middleware, OS, etc. in the middle of the project (unplanned) loss of expertise due to turnover or illness
· Lack of time, critical input and feedback from key users
· Poor time estimates based on incomplete information
· Front end lowballing (showing favorable ROI) from business management wanting their project to not only get the go ahead in a tight budget year but also to be put ahead of others in the organization
· User resistance to change
On the last point, let's be fair. Many times, users at the lower levels only see one set of functions. Working with the old system, they may have keystrokes memorized, know when to take their breaks (process runs may take 30 min. to complete) and know what to look for if something goes wrong. In their mind, “F9” always posts a transaction; why can’t the new system work the same way? So from their standpoint, system change equals a temporary loss of expertise, extra work and usually a multitude of errors in the first few days or weeks of implementation. And again, from their perspective, where’s the upside? Some users actually choose to retire rather than climb the new system learning curve.
The industry statistics for project success are depressing. Following are 2015 numbers prepared by the project management firm Wrike:
For organizations that use a methodology:
· 38% meet budget
· 28% stay on schedule
· 71% meet scope
· 68% meet quality standards
· 60% meet expected benefits
For organizations that do not use a methodology:
· 31% meet budget
· 21% stay on schedule
· 61% meet scope
· 60% meet quality standards
· 51% meet expected benefits
We wish we could show you a more dramatic improvement when using a methodology rather than "seat of the pants" management but that is not the case. Think of it this way—if a project fails and you have not used a methodology, your professionalism/rationale may be questioned. If a project methodology is in place, then at least you haven't skipped the basics.
To get projects to completion you need two things: first, standard project management tools, such as reporting, Gantt charts, critical path, structured and frequent communications. Second, you need a clear methodology such as waterfall, critical path method, scrum within the agile framework or a hybrid.
How to manage project risk? Answer: Like drinking a Louis XIII de Remy Martin Cognac, one sip at a time.
If you keep subdividing a large project into smaller steps, at some point the risk nearly vanishes for that one step. For example, reading a transaction database and summarizing all transactions over $100 is pretty straightforward. Any problem in the step shows up immediately and can be fixed immediately. Also, you know that it should take hours, not weeks to complete. You could continue to add small, It’s when those small segments of code are combined into a much larger system that special care is required to ensure interoperability errors and complexity do not sink the project.
So the question becomes: How do I make the risk profile of a major system look more like I’m sipping a Louis XIII de Remy Martin Cognac?
Success markers
Imagine you’re meeting an executive recruiter at Starbucks. She’s trying to get an objective assessment of your management and project skills so she can pitch you to the right prospects. She will not be looking for one thing or skill. Instead, she’ll be looking for a collection of behaviors/processes that accompany strong project management skills:
· Monster sized projects are broken up into achievable and measurable sub projects.
· Projects are well defined, both technically and functionally. It might be a paperless project, but if printed out, the specs may be a foot thick. Perhaps they are done on the fly with scrum but the details are there in some form beyond the developer’s brain
· Teams are defined at the "pizza" size—small enough that a couple of large pizzas will feed every one of the team
· Good reporting systems help team leaders manage projects Email is not the primary management tool
· Meetings are short (standups), with feedback from all members of the teams discussing progress, issues and roadblocks
· Milestones are clear (the more detailed and low level, the better)
· A good system is in place for reporting, tracking, alerting of potential roadblocks or issues and quantifying progress
Projects succeed when you have the right tools in place and the right training for the teams. Most firms today are using some variation of agile methodology. Tools such as Jira and Axosoft are the day-to-day workhorses needed to run your projects. Some of the essential features include:
· Project and issue tracking -- bugs, status, documentation of topics to be discussed
· Resource tracking and planning (important for xShore teams where cultural holidays and vacations play an important role in resource planning
· Scrum support (see illustration below)
· Kanban. Enables matching of the amount of work in progress to the development team's capability. A team's work can be visualized with screen shots, blockers and dependencies immediately identified and resolution implemented. The Kanban board has a three-step process: 1) To do 2) in progress and 3) completed
· Prioritizing backlog, assisted by user stories
· Integration with developer tools
· Availability of add-ins
· Estimations of completion times for tasks and subtasks
· Status synchronization for the entire team -- everyone is on the same page
· Actionable results
· Release planning to layout short iteration cycles and break down releases in shorter sprints
· Methods, including timers, to keep meetings short and on track
· Burndown charts and speedometer visualizers to measure velocity
· Standard views such as Gantt and calendar
· Change notifications for team members (especially important for geographically separate teams)
· Integration/tracking Apps on Android and iOS
Bottom line for the CIO: break projects into manageable segments; use good quality project management tools; manage risk rather than ignoring it and keep everyone talking.
