I’ve had the good fortune to have been involved in many successful application development and analytics efforts (here and here), and a few that were less so (here and here). Recently, I’ve thought about the differences between the successful and the unsuccessful.
As I see it, there are five general characteristics that the successful endeavors share. They:
- Closely Align with the Business
- Share an End State Vision
- Are Reality Grounded
- Have a Technically Competent Team
- Feature Frequent and Open Communications
To level set, this article focuses on business-facing analytics, data acquisition, application development, and related efforts developing internal capabilities for larger organizations.
Closely Aligned with the Business
It stands to reason those paying for a project that builds a new capability know how it benefits them. However, if business processes are poorly defined, or stakeholders aren’t fully on board, or the project team is out of sync with business objectives, then the project founders as its work products prove out of step with business needs.
On successful projects:
- Strategic and tactical business objectives are well defined, and they support the business unit’s objectives
- Consensus critical success factors are documented
- Proposed changes to business processes are defined
- Business requirements are documented and a requirements change process is defined.
Business definition provides context for more detailed process and technical definition. Without that context, your project will struggle. My rule of thumb: if it is difficult to lay your hands on strategic goals and business unit objectives, then they probably don’t exist, or aren’t relevant. In that case, work with your project sponsor to ensure that project goals are well supported by stakeholders.
Share an End State Vision
In any business effort, participants have a mental picture of the end result. That mental picture shapes the direction and content of their work. Project leaders must ensure that all participants share the same mental picture of the final outcome so that diverse and dispersed parts come together into a unified result.
Developing that highest level view is equal parts technology and art. A high-level visualization of the outcome is effective inasmuch as it is meaningful to all participants, thereby unifying all of the different stakeholders in their efforts. The larger and more complex the system, the more critical that the efforts of the large and diverse team working on the project share a common understand of the goal through a well executed high level visualization.
Examples abound in big and famous technology initiatives. Here are a couple:
- The International Standards Organization Open Systems Interconnection model is the standard conceptual view of communications between networked components. Originated by Hubert Zimmerman around 1980 to address the need for “standards which would allow constitution of heterogeneous computer networks”, the model enables developers to conceptualize communications between two network nodes at any of its seven layers of abstraction.
- Werner von Braun used high level visualizations to both unify NASA’s moon shot development and to build public support in his work with Colliers magazine and Disney.
Your program may not be as fundamental as the OSI model, or as far reaching as space travel, but giving all participants the same mental picture of the outcome will help ensure everyone is on the same page.
Reality Grounded
It goes without saying that no one should try to build a technically unfeasible product, and in my career I haven’t seen that attempted. However, as a consultant I’ve been witness to several that were insufficiently resourced or insufficiently supported for the objectives at hand.
The cases I’ve seen came in one of two flavors:
- Sponsors out of touch with the true scale of the work: sometimes those pushing the project lack understanding or attempt to conceal an initiative’s cost in resources or funding, or don’t comprehend the technology leap a project might involve relative to an organization’s current technical foundation and culture.
- Lack of unity among stakeholders about the value of the work: In these cases, disunity among the stakeholders causes the project to founder at the first challenge. I managed one consulting project where the project sponsor quit the company, and the other stakeholders immediately cancelled the project and settled with our company with the work half done.
Technical rigor in project definition and throughout the effort, clear eyed cost analysis, and constant cultivation of strong stakeholder support ensure that the project starts and remains grounded in reality and its goals are within reach.
Technically Competent
Beyond being well founded technically and supported by stakeholders, successful development requires expertise among key project leaders and team members. Early planning should include an architect with deep experience in selected technologies. As the team assembles, a representative sample of senior team members should be similarly deep in the tools at hand, and capable of guiding component design and training other team members.
It is important that these leaders have experience in the specific tools the project has selected. Don’t think that deep experience in tools of the same class will do. For example, Teradata, Oracle, and SQL Server are all relational DBMSs, and a senior expert in Teradata, for example, can quickly come up to speed enough to operate in SQL Server. However, the two products are structured differently. Table design, query design, and development practices are superficially similar but different behind the scenes, and are transferable only after ramp up in the company of those initiated in the tool.
Frequent and Open Communications
Last but not least, successful teams work together. Project leaders, and the organization as a whole, reinforce the value of each team member, and build processes that invite broad participation in planning. Frameworks for managing agile development at enterprise scale, described here, can channel team members’ input productively. Not every decision is by consensus, but the frameworks provide structures within which everyone can have their say.
Beyond effective management/team member interaction, intra-team communications are critical to effective development. In these days of geographically diverse work, co-location has become an impossible dream. Remote workers need Slack, MS Teams, Sococo, or a similar tool to openly and freely share comments, respond to questions, and to build relations by just joking around. I can’t think of a recent time I’ve been stuck on a programming problem and the answer didn’t arrive after a quick Teams post. And there have been many times when a well chosen GIF arrives to lighten up my day. Here and here are a couple of links on how to promote good team communications.
In my experience, projects that closely align with the business, share an end state vision, are reality grounded, have a technically competent team, and feature frequent and open communications are the ones that succeed. Take care of these five qualities and success will take care if itself.