In the book, There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change, Bob Lewis and co-author Dave Kaiser analyzed and discussed the new ways of thinking about IT and business management.

These are some of my takeaways from reading the book.

In the “BusOps” chapter, Bob and Dave discussed the role of IT operations in making the intentional business change.

We often think of IT operations as a service provider to internal business customers. That is an outdated concept. The practice of the negotiated service level agreements (SLAs) between IT operations and its internal customers is counter-productive for two reasons.

First, the technical SLAs are pointless because we live in a 24×7 world where the business is always operating somewhere in a time zone. The days of computer systems going down are over. Amazon and Google do not go down, and that sort of operational style is now considered a norm.

Second, the service-related SLAs are also outdated because internally facing SLAs cannot be enforced like a legal contract. The organization still needs to measure its operational effectiveness, but it should be done with carefully designed service performance metrics, not SLAs.

The concept of DevOps in IT is a good starting point, but we should not stop there. Business operations and IT operations have a great deal in common these days because we live in a technology-enabled business environment.

Going “digital” is a natural way of doing business because conducting business with technology is no longer optional. As a result, Business and IT operations are inextricably linked. We now live in a “BusOps” environment. The integration between Business and IT is a new way of going forward.

So, what can be done to address BusOps opportunities and challenges? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter Four. I highly recommend the book.

In the book, There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change, Bob Lewis and co-author Dave Kaiser analyzed and discussed the new ways of thinking about IT and business management.

These are some of my takeaways from reading the book.

In the “Fixing Agile” chapter, Bob and Dave discussed the advantages and challenges for adapting the Agile methodology for building our IT solutions.

The best way to adopt Agile is to treat it as a mindset rather than simply a set of techniques. Practicing Agile requires us to establish and maintain a direct and iterative developer-to-user interaction. Delivering incremental deliverables and tangible results will further increase Agile’s chance for success.

The bigger the change, the higher the chance of something will not go as planned. Most multiyear projects fail in part due to their complexity. The incremental approach of Agile can help us make better planning decisions for the larger business change we hope to undertake.

Agile may be defined as a software product delivery methodology, but we can leverage Agile to do more. If there is no such thing as an IT project and only intentional business change, we should find ways to adapt Agile for facilitating business changes. Enhancing Agile for such effort will involve delivering business change in tandem with COTS/SaaS implementations as well as synchronizing Agile with strategic planning.

So, what can be done to address the agile adoption challenges? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter Three. I highly recommend the book.

In the book, There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change, Bob Lewis and co-author Dave Kaiser analyzed and discussed the new ways of thinking about IT and business management.

These are some of my takeaways from reading the book.

In “The New Business/IT Conversation” chapter, Bob and Dave outlined three types of business change that can benefit from better information technology. They are 1) business function optimization, 2) experience engineering, and 3) decision support.

Business function optimization is about getting the work done and done better. Experience engineering is about improving the experience everyone has when getting the work done. Decision support is about helping decision-makers make more effective decisions. Facilitating and making these types of business change happen should be the standard of competence for all IT organizations.

For IT, the question we used to ask was, what does the business want the software/system to do? The new question IT should be asking is how the business wants to do its work differently and better?

Business processes (how the product/service gets put together) and practices (the organization’s knowledge and experience) are different. They are the two poles of the continuum of how the organization gets its work done. IT should help a business figure out where on the continuum a specific business function should be placed to better design a system that can support it.

IT can help businesses better design their function only after understanding the input and output required by the business. The input and output are further influenced by six optimization factors: fixed cost, incremental cost, cycle time, throughput, quality, and excellence. It is not possible to optimize them all because there are constraints and trade-offs.

Designing external customer or internal user experience is complicated. Bob and Dave suggested IT start by setting this goal: “make their experience as un-irritating as possible.”

Finally, designing a decision support system is pointless until the organization adopts a culture of honest inquiry. Decision support systems are valuable only to the extent they reinforce this culture.

So, what can be done to address the new business/IT conversation? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter Two. I highly recommend the book.

In the book, There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change, Bob Lewis and co-author Dave Kaiser analyzed and discussed the new ways of thinking about IT and business management.

These are some of my takeaways from reading the book.

The whole point of the book is that our approach for implementing and managing information technology projects has been wrong. There is no such thing as an IT project because what we are trying to do is to achieve an intentional business change with the help of information technology.

When we try to achieve business transformation or change via an IT project mentality, we often set ourselves up for disengaged stakeholders, low return from the investment, and, more often than we like to admit, outright failures. When organizations implement IT projects, we create a situation where IT and the business can point the finger at the other and give themselves an excuse for anything that can go wrong.

The first thing to do in changing the IT project mentality is to change the organizational culture.

Culture can be explained as “how we do things around here.” Culture is the combination of our attitudes, shared knowledge, expectations, and values expressed in a common but specialized vocabulary.

Culture can also be expressed in terms of the employees’ learned behaviors in response to their environment. The standard operating procedures do not adequately articulate the organization’s culture; however, culture is the unofficial policy manual.

The culture change of No-IT-Project cannot be done via proclamation but rather with influence. The culture’s influence also flows from the top down the organization. For the leader to change her organization’s culture, she must lead by example.

Because culture defines “how we do things around here,” successful, intentional business changes can only come from a shared focus on the desired business change. If the organization’s culture is to treat business changes as departmental projects, the No-IT-Project movement is unlikely to take hold.

Because many organizations view the IT and business relationship as technology supplier vs. internal customers, it is very difficult to build a closely collaborative relationship on a transaction-oriented foundation. The customer-supplier relationship encourages silo-like thinking and might be the biggest barrier for moving towards the No-IT-Project and intentional business change approach.

So what can be done to address the culture obstacles? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter One. I highly recommend the book.