The Right Approach Makes All the Difference
In the workplace, the advancement of technology often outpaces the ability of business to keep up. Organizations are forced to upgrade to the latest technology stack to enhance operational efficiency or to gain a competitive edge. Yet technology projects are some of the riskiest investments for an organization to undertake, with nearly two-thirds of technology initiatives failing altogether, or reaching only modest levels of enhanced performance.
THE HOSTILE PROJECT ENVIRONMENT
CHOOSE YOUR WEAPON
Different types of projects benefit from different lifecycle models, such as a modified waterfall approach (above) or a hybrid agile scrum methodology (below). Make sure you’re using the right approach for your project, and ensure the team understands the entire process and all artifacts involved throughout the delivery cycle.
So why are technology-based programs so challenging to successfully implement, especially given that the newly deployed technology is brought onboard to introduce fresh capability gains? Common reasons include the typical fuzzy suspects: fuzzy vision, fuzzy stakeholder involvement, fuzzy requirements, fuzzy scope definition, fuzzy communications, fuzzy integration, all delivered under a fuzzy product lifecycle.
At the core is the predominant harbinger of technology implementation failure: the disintegration of current business process under the refreshed technology, and inability to rapidly adapt critical workflows to the new system.
The resultant process gap, loss of productivity, and additional expenditures can be expensive, and in some cases, too much for the organization to overcome - implementation costs are usually many millions of dollars over several years for complex enterprise-wide IT systems. And that's before the system goes live. And that's if all goes according to plan.
FOCUS ON THE FUNDAMENTALS
More than any other single factor and regardless of the process model, communication is the bellwether of any successfully executed program; this includes fully communicating the life-cycle model that the team is using to deliver its product.
On new projects or newly formed teams, it’s worth taking a moment with the team and stakeholders to enhance their familiarity with the lifecycle model planned for the project. For example, simply because the team is developing software components and is primarily composed of software engineers does not necessarily mean they understand the intricacies and flow of an agile process.
Be specific: for example, if they’ve used agile, which model did they use – Kanban, Scrum, extreme/paired programming, evolutionary prototyping? While similar, these models have some fundamental differences in terms of how the team interacts, how milestones are developed, and how deliverables are created. Finally, don’t assume that because they’re software developers they’ve used agile at all – some experienced coding teams use waterfall (or a modified sashimi version), based on the organizational or customer delivery model.
Compounding the issue of lifecycle selection is that there are many variations on each theme; in response, it’s not unusual for organizations or departments to define their own product lifecycle model. Often this process is derived organically or loosely based on best practices of the industry: waterfall, agile, hybrid models, or mixed systems engineering, and it’s generally a tailorable, gated method. Decision points, indicating detailed project performance through key indicators, provide appropriate exit ramps for underperforming initiatives.
Whether you’re building a large construction project, developing custom software, or implementing an integrated project, the path to success begins with selecting and communicating the right process model(s) and overall delivery approach for your project.
