The Seven Core Principles of Digital Transformation

Digital Transformation

Digital Transformation has become a hot buzzword recently, being adopted by Microsoft as the overarching theme for their cloud based business apps and the subject of many studies from McKinsey and company, Gartner and other research firms.

I wanted to share some of our approach and lessons learned working with companies in different industries such as Insurance and Manufacturing on their digital transformation initiatives.

A transformation does not happen overnight. It is a long and sometimes painful process that to be honest, never really ends. The rate of innovation and change is increasing and new business and customer needs will constantly emerge.

Therefore, our approach is very much grounded in the concepts of agility. The right foundation built with change in mind. In such an approach, it is not always beneficial to try and document every future requirement to see how to accommodate it but to have a very strong foundation and an agile, open framework that can be easily adapted.

A good way to judge your current agility level is to perform a Digital Agility Gap test. For small, medium size and large changes business has requested in the last year, what is the gap between when the business would like to see the change made to when your organization was able to deploy? The larger the gap, the more acute the need is for a comprehensive digital transformation.

agility-gap

The following 7 core principles should drive every digital transformation initiative, large or small:

  • Business Driven. This may sound obvious but all digital initiatives need to have a business reasoning and business sponsor. Technology can be a game changer but very often, the digital channel needs to be part of an omni-channel approach. eCommerce can augment retails stores or distribution channels but will not replace them for a long while. Digital must be part of the overall business and market strategy. The new role of Chief Digital Officer is a great example for how organizations integrate the digital as a business channel with broad responsibilities and a chair at the executive table. The Digital aspect needs to be part of every major organizational strategy, not a separate one. For example: you are launching a new product, how will you design it, support the manufacturing/supply chain, market, sale and support the product using Digital means?
  • Data is King. Having enterprise information available in digital format with a single source for the truth is the absolute foundation of a digital transformation. Without “Good data” the effect of garbage in, garbage out will produce inconsistent results and systems people can’t trust. This is usually the hardest part for many companies as organizational data may be residing in many legacy systems and too intimately tied to old business applications. It also is hard work. Hard to understand and hard to put a direct ROI on. It is not glamorous and will not be visible to most people. In lieu of complete data re-architecture, most organizations start with master data management and data warehouse / operational datamarts to get around the limitations of the various systems where data is actually stored. The imperative is to know what the single source of the truth is and abstract the details through data access layer and services. The emerging area of Big Data allows capturing and processing ever larger amounts of data, especially related to customer interactions. Data flows, validation and storage needs to be looked at again with new vision into what and how data is captured, stored, processed and managed.
  • Actionable Analytics. Many organizations invested heavily in Business Intelligence and use decision support systems to run analysis and produce reports. The expanding scope of data capture and processing now allows analytics to serve as actionable triggers for real time decisions and other systems. For example, your website’s ability to make customer specific product recommendation can be a result of real time process that conducts a customer analysis and what similar customers have bought and can execute an RFM analysis to assign a tier to the customer and derive relevant offers. Marketing campaigns can target prospects based on predictive analytics etc. Closed loop analysis is critical for understanding the impact of decisions or campaigns. The ability to see the connection between an offer or search campaign and the revenue it generated is the foundation of future investment decisions.
  • Customer Centricity. One of the main drivers and benefits of the digital transformation is the ability to meet the new world of customer expectations and needs. Customers want access to information and ability to take action and interact anytime, anyplace, from any device. The new Digital Experience maps to the customer lifecycle, journey or buying flow and data is collected at every point of interaction to feed personalization, targeting and marketing. When done correctly, an intelligent user experience will improve engagement, loyalty and conversion. In designing new digital user experience, we usually recommend mapping the user interactions across all touch points and focusing on finding common needs rather than a “Persona” driven approach. Those in our experience are too generic and lead to oversimplification of the model.
  • Agility in Technology and Process. Agility is at the heart of our approach and without it you would go through a transformation every few years. It is broader than just IT and impacts many business and operational processes. Few key concepts of planning for agility:
    • De-coupling. A large part of what makes changes hard, is the intertwined nature of most IT environments. Proprietary databases, older applications without outside interfaces, hard coded database calls in code, heavily customized but dated applications, etc. The solution is to de-couple the elements and create a modular, service oriented architecture. Data should be separated from logic, services, and user interaction allowing each tier to grow and evolve without requiring complete system re-write. For example, the biggest driver of transformation in the last few years has been the user experience and the need to support users in various mobile devices. A de-coupled architecture would allow UX overhaul using the same services and backend.
    • Agile / Rapid application development. Application development needs to be able to create prototypes and test ideas on a regular basis. For that to happen, the process of definition, design, implementation and testing software has to be more responsive to business needs. Whether following Agile Methodology principles or just a more iterative version of traditional models, application development has to be able to quickly show business users what they would get, and adopt a minimal viable product approach to releasing software. An emerging model of continuous delivery allows faster, automated deployment of software when it is ready.
    • Cloud and Infrastructure agility. The emergence of cloud services is making agile environments so much easier to implement. From an infrastructure perspective, you no longer need to invest in hardware resources for your worst-case load scenario. The ability to get just as much computing resources as needed on demand and scale as needed in matter of minutes makes platforms like AWS and Azure very appealing. Many applications now offer only cloud based versions and even the large players like Microsoft and Oracle are now pressuring all customers to get on the cloud versions of their applications. The ability easily to plug a cloud application into the environment is the ideal of agility. With a common security and authentication layer, the modern corporate application landscape is comprised of many different cloud applications being available to each user based on their role and integrated to a degree that makes the user experience as seamless as possible.
    • In addition to the environment, software and infrastructure, organizational processes have to be more flexible too. Change management needs to become a process that enables change, not one the stops it.
  • Process Automation: with the new landscape comprised of so many different and independent application, process automation and leverages the open interfaces of application is becoming critical. Traditional Business Process Management application are now morphing into cloud orchestration and an ability to allow processes to be created across multiple applications and managed / updated by business users without IT involvement.
  • Security. Last but not least, the open, flexible nature of the future landscape we were describing here, requires new levels of security that should be an integral part of all facets of the environment. Data security and encryption. Services security, security in application design, all layers and components have to consider the rising threat of hacking, stealing data and denial of service that are more prevalent than ever. We see this as the primary concern for companies looking to adopt a more digital and agile environment and a large emphasis on risk management, security standards and audits should be a primary component of any digital transformation initiative.
blended project management

Have you tried to blend agile methodologies into your traditional waterfall world?

Did you get a tasty stew?

….Or a culinary disaster?

I like to cook, but I’m not exactly a purist.  By that I mean that I almost never follow a recipe exactly.  Instead I treat a recipe as more of a guide.  Sometimes I omit ingredients that my family doesn’t like; other times I add in ingredients to see what the affect will be. I often combine a couple of recipes together, mixing and blending ideas from several sources.  Sometimes the result is a wonderful creation that suits the tastes of my family.  Other times, we take a bite and reach for the pile of take-out menus.

I find myself taking the same approach to development methodologies.  Like most of you, I find traditional, waterfall methodologies to be too rigid, too slow, and too removed from reality.  Their assumption that everything about a project can be known and documented up front has always struck me as laughable.

But when I look at pure agile methodologies, I find them too rigid and idealistic as well.  Successful projects need a framework around them; they can’t be driven simply by empowering a team to prioritize a backlog and deliver chunks of code.  Project components need to be fit into a larger vision and architecture; organizations need to have a sense of scope, plan, and budget.  Large, complex systems can’t always be nicely packaged in 2 or 3 week sprints.

So I find myself mixing and blending.  Take a few waterfall concepts like a defined project scope, written business requirements, defined technical architecture, and a project plan.  Blend with an agile development window where the project team can work through detailed requirements, development, and testing together; shifting priorities as business needs change.  Garnish with some user testing, training, and release planning.

Maybe this is agile book-ended by just enough waterfall to frame the work that the agile teams will take-on and integrate their work with the organization’s larger planning processes.  Maybe this is diluting agile precepts by subjugating them to overreaching controls.  Some call these approaches “waterscrumfall”; some call them an abomination.

My experience (and the experience of at least one of my colleagues) has been that a pragmatic blending better suits the needs of most projects and most organizations. It creates just enough structure to tame the chaos while recognizing that projects can’t be and shouldn’t be totally defined up-front.  It ensures that project deliverables fit into the larger enterprise architecture and meet strategic objectives.  Yet it takes advantage of the agile team’s strengths, allowing them to drive the project’s pace and details.

What has your experience been?  Have you tried more blended approaches?  Have they been successful?  Or have they resulted in the equivalent of a culinary disaster?

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

One Size Does Not Fit All

One size fits allHave you been to the mall and purchased a shirt that says “one size fits all” for the size?  While the shirt may fit some of us perfectly, it might be too large or too small for others.  The same goes for a project.  This “one size fits all” mentality for all projects can put your smaller projects at great risk by bogging them down in a project management methodology that is too rigorous for the size of these projects.

 So what can you do?

Establish a flexible project management methodology framework

  1. Define what a “small” and “large” project is in your organization (e.g., a small project can be between 6 – 12 weeks and a large project is anything greater than 12 weeks)
  2. Identify the deliverables or documents needed for each project type
  3. Monitor smaller projects to validate the success/failure rate of these projects and adjust the deliverables within the framework as necessary

The key point to remember is that the project management methodology is a framework for all projects, not a straitjacket.  The framework needs flexibility to support all projects, no matter their size, while producing results.

One size really does not fit all, so find the size that fits your needs to successfully manage your small project.

5 Warning signs that your methodology needs a reset

Project methodologies tend to grow dysfunctional as time goes on.  The breadth of their standardization increases until the only person who really knows how to use it is the methodology owner.

Too many templates, too many standards, too many hours required for initial training and training on new templates and standards, and perhaps too many good resources moving on to other employers with a less rigid approach.

To find out if your project management methodology is heading down the wrong path, look for these warning signs:

  1. You have a full time position dedicated to policing methodology compliance
  2. Your methodology manages by standard and template instead of by desired outcome and requirements
  3. Your methodology continues to get bigger over time, and details with little or minor influence on success have never been pared away
  4. Your projects are taking longer to implement
  5. Your project sponsors are growing more frustrated with each project you attempt to implement

resetThe methodology should be a guideline, not a noose, for organizational projects  – supporting the strategic goals of the organizational ecosystem instead of drowning in a pool of standardization. If you see any of these warning signs, maybe it’s time to hit the reset button.

 

Avoiding Agile Anarchy

Agile project management

Conventional Agile Methodology Wisdom lists three factors that define an Agile-ready project:

  1. High Uniqueness
  2. High Complexity
  3. Aggressive Deadlines

After using these three parameters to select your first agile project, there is still legwork to be done before sprints are humming along.

Many agile initiatives are announced by fiat with the team structure, sprint length and other basic rules of the road mandated by the Agile Initiative Sponsor. They dive right into development sprints, gathering user stories along the way to build a backlog. Here are some ways this approach could backfire:

  • In a rigid, hierarchical organization, the ability of teams to self-organize is often historically non-existent, and the change management hurdle might be a gap too big to jump. There are many ways that interoffice personalities and politics can sink an agile initiative in its early stages, or at any point along the way.
  • Complex, unique projects require some upfront work on architecture before the development sprints can begin. Agile teams can best manage this by making the first few sprints architecture sprints. Time and again, we have seen horror stories when the overall design or architecture is glossed over:
    • Parallel agile teams within a business design disparate UI’s to enable functionality that is essentially the same, but serves the needs of one particular product group. Before long, it’s obvious that external stakeholders are confused and put off by having to remember two different ways of interacting with the same company
    • User stories are taken down as the basis for development sprints, but they fail to consider the secondary stakeholders. BI reporting needs are often missed.
    • Prioritization of the backlog is driven by business need, without any attention to building foundational pieces first, then layering on transactions.

In short, Agile without Architecture leads to Anarchy, and a lasting bad impression that will taint future Agile efforts. It’s best to look before you leap and take time to address any Agile readiness gaps.

 

When I grow up…a project manager’s path to the future

when you grow upWhen you were young, I bet you said “I want to be a project manager when I grow up!”

Probably not, since most of us plunged into project management the old fashion way – by accident. Someone probably approached you and said, “I want you to manage this project.” I bet you scratched your head and thought, “Ok, what next?”

Typically, companies don’t have career paths for project managers.  Project management is generally not seen as a core competency, so  career paths or training aren’t a priority. This reality leaves the project manager frustrated as their career seems to stall.

Another career conundrum: who wants a “new” project manager running the project? How else can project managers learn and gain experience? They can be mentored by a more experienced project manager, but mentorship is an area lacking in most organizations.

So what do we do? Here are some suggestions.

First, identify what your company CAN do to continue your growth as a project manager:

  • Work with your human resources department to create a career path, including continuing education and certification
  • Expand your sphere of impact by implementing project management methodologies, processes, and governance mechanisms to improve productivity across your company
  • Create a mentorship program. While we share some skill sets that make us good project managers, we can still learn from one another

Second, identify what YOU can do to continue your growth outside of work. Remember, it is our responsibility as project managers to continuously learn and apply this knowledge to our projects. Take charge of your growth as a project manager!

  • Join professional organizations like the Project Management Institute (PMI) which, through local chapters, communities of practice and other events, provides additional learning opportunities and certifications branching across the project management universe
  • Think outside the box and identify other opportunities, such as mentoring, to learn and grow as a project manager

Companies want to hire the best talent, but like other professions the company and the project managers need to share in their career growth and development. This is a win-win all around for the company and the project manager.

So back to my question, what do you want to be when you grow up? Me, I want to be a Project Manager.

Are you ready for Agile?

agileMany companies are moving from the traditional Waterfall project management methodology to Agile.  Why?  Agile fits today’s fast-paced organizations and allows them to easily adapt their project portfolios as business priorities change.  It also allows organizations to better respond to customer needs and stay competitive.

If you are ready, here are five tips for transitioning to Agile:

1.  Perform a readiness assessment of the organization

  • Determine if your organization is ready for Agile
  • Ensure the organization understands how Agile works

2.  Educate the team and the organization about Agile

  • Define roles and responsibilities of the Agile team
  • Train the team on their roles and responsibilities

3.  Provide decision-making authority to the Agile team

  • Ensure the team has the authority and decision-making ability
  • Ensure that team members feel capable to step into decision-making roles
  • Guarantee management support

4.  Start with a pilot project

  • Identify a project
  • Set up the team infrastructure

5.  Have an Agile Evangelist

  • Support the Agile team (and organization)
  • Provide recommendations to the team

Many companies try to jump into agile, get frustrated, and run-away from the experience.   It takes thought and preparation to make the transition a successful one.  Agile just doesn’t happen.  You have to make it happen.  But the rewards are worth the journey.

Project Management Resolutions for 2014

resolutions-catIt’s that time again folks.  New Year’s Resolutions. Been a few years since we did project management new year’s resolutions, so here’s what I am offering up based on this year’s project experiences.

1Make change management integral to your project management methodology. If it’s considered a separate discipline, it can often get left by the wayside with disastrous results. It’s the project manager’s responsibility to make sure that there are tasks in the plan that pertain to the people-readiness for the go-live of any project.

2. Document meetings in project artifacts, then link or copy into minimalist meeting notes. Back in 2010, we talked about limiting meeting attendance, let’s talk today about eliminating or minimizing meeting minutes. The way to do this is to parse the meeting content directly into project artifacts. Actions go in an action log and issues go in an issues log or register or whatever your flavor of project management calls it.

3. Simplify. Simplify ruthlessly.  Instead of adding to your methodology, look for ways to streamline it and cut it back. You may find that you get better adoption of your pm methodology when less is more. The trick is in knowing where and when less is appropriate.

4. Broaden your knowledge base. Read new and different blogs and books, delve into business journals, neoroscience, leadership, psychology, sociology and other seemingly peripheral topics. You would be surprised at the creativity it sparks in your thinking and approach to your projects.  My favorite ways to do this include:

5. Embrace new tools.  The rumble from the trenches is starting to include disatisfaction with MS Project as the be-all and end-all of project management tools. Have you looked into alternatives yet? Sometimes it’s actually simpler to manage projects with Excel.   Are you using social media effectively to manage, motivate and communicate with your project teams? Be especially alert for tools that can help you simplify to achieve resolution #3.

Let’s grow this list:

  • How are you looking to change the way you manage projects in 2014?
  • What new tools are you going to explore?
  • What’s on your reading list?