Copyright to Bill Monroe, © 2014 Quality Project Delivery Ltd. All rights reserved.
Originally published as a blog on LinkedIn March 2014 and content extracted for publication here June 2014.

Editor's Note | Distinguishing between "Business" and "IT" | Drivers for Projects
A Question of Semantics | Bill's Reasoning | Conclusion | Different Types of Project

Drivers for Projects

Praveen Malik: Bill, I agree that "Business" is the driver for many projects. On the other hand, "Business" is not a driver for all projects. There are many non-profitable/social projects that are done by Govt./Quasi Govt. org. On the other hand we need to make a distinction. If we don't there would be no "Vehicle design" projects, no "Road" projects, no "Power" projects etc. For doing projects "Application Area" knowledge is integral. E.g. a "Banking IT" project cannot be done without both IT and Banking knowledge.

Bill Monroe: Hi Praveen, When you say that, "There are many non-profitable/ social projects which are done by Govt./Quasi Govt. org …" in those cases the strategic leadership for those organizations are analogous to "Business" in my example. I'm referring to the fact that justification and funding for all projects must come from those in the organization who are responsible to see that resources are applied in ways that best further the interests of the enterprise. This is also why I mentioned earlier that departmental justification of projects could be detrimental to the interests of the enterprise as a whole.

I agree 100% with your statement that, "… a 'Banking IT' project cannot be done without IT knowledge and Banking knowledge." This is the idea that I try to symbolize in my logo: The greatest probability for project success comes from effective collaboration from Senior Managers (who understand the strategic direction and imperatives of the business), Business Professionals (who understand the business processes that enable daily work to be performed), and Technology Professionals (who understand the systems that support and enable business processes).

Each of these three groups has knowledge that is critical to project success and, in many cases, is not known by the other two groups. This is why effective collaboration is crucial for project success.

Gurpreet Dulai: Bill, I think there is a semantics issue at play here. Sure, technically speaking, a project is just a "project", regardless of which industry is being referenced. However, based on my experience, a project is always linked to one degree or another to the industry it is being conducted for.

Cruz Gracia: When IT is viewed as a commodity, or a utility, that's when "IT" and "Business" gets put into separate camps. However, when IT is in the same realm as Finance, Marketing and Accounting, that's when "IT projects" matter. One-way or the other, every facet of business gets touched by IT. Business decisions at all levels need to be coordinated with IT if there is to be a significant impact to business.

This isn't the 90s where IT was buying tech for the sake of buying tech. CIOs (or rather good ones) now have to choose how to buy tech based on how business will be leveraged by that tech. Will replacing that ERP system, for example, increase ROI? A CIO with a business background will have to make that kind of determination. The days of IT being merely a cost center instead of a profit center are slowly coming to an end.

Sergio Luis Conte: The problem here is the misuse of the word "Business". An organization could participate in several businesses according its organizational strategy. The reason for starting an endeavor (i.e. project) is to put the organizational strategy into action. And when you define your strategy you must define the field (the business) where you intend to compete because the strategy is the way you will compete in that field. The way to put in place the transformation needed, the organizational architecture to compete according to the defined strategy, is to start a project. So, an organizational unit does not own the project, it is owned by the business.

If from the very beginning you fail to communicate that you will have a lot of problems in executing your endeavor. For example, when seeking human resources, how many times you have heard: "It is an IT project, so why must I give you my people to work in that project?" I believe that the key to avoiding this type of situation is to promulgate to all business departments that the project belongs to the whole business, not to a business unit. That's because, if the project fails, it jeopardizes the survival of the whole organization.

Distinguishing between   Distinguishing between "Business" and "IT"

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page