Tag: business process
On the nature of IT projects
IT projects versus business projects. Confusing the two is more common than you think…and the results are often disastrous. Unfortunately, most stakeholders –managers, end users and IT professionals alike – frequently fail to understand the distinction.
What type of project is this?
I recently sent an SOW (statement of work) to a potential client proposing assistance with a complex business process project – an EHR (electronic health records) implementation that was off track. The client pasted a summary of my offering in an e-mail and sent it to a colleague in the IT Infrastructure business, apparently seeking a better price. My colleague immediately realized this was not in his bailiwick and he forwarded the e-mail to me! Questionable business ethics on the client’s part notwithstanding, the client was fortunate that my colleague apprehended the nature of the project and understood that none of his staff members were qualified to perform the services.
A less ethical vendor would have been happy to dispatch an employee to run up billable hours without having any idea of how to identify and resolve the underlying causes. Industry-specific workflow, regulatory requirements, and complex reporting are not typically part of the toolkit of IT Infrastructure professionals. Customers are sometimes unable to understand this concept. The way they see it:
Software not meeting business needs? Call IT
The truth that their problems are of a business process nature rather than technical is not immediately apparent to many end users and managers. Some immediately see the difference between process issues and technical ones as self-evident, others grasp it quickly with some explanation, and a few never understand the difference no matter how much explanation one provides. Technology should never be applied until all the processes are completely understood, but I have encountered plenty of CIOs and other professionals who are unable to comprehend this.
Enter the business analyst
Many organizations now employ “business analysts” to create a bridge between IT and business lines. It is a great concept, but sometimes these folks are just techs with a slightly better wardrobe. When they use words like paradigm and leverage, it’s a dead giveaway that they’re faking it. The same goes for consultants.
Something I have seen a few times is a troop of business analysts, IT managers, and project managers scratching their heads, wondering why their eight-figure project is grossly over-budget yet performing so poorly. Often, these people have been working for the organization for years but can’t answer basic questions about processes, quality assurance, compliance and workflow. I have this old fashioned notion – in return for a cushy six-figure salary, one should be able to answer these sorts of questions.
What exactly is an IT project?
Is ERP (enterprise resource planning) procurement and implementation an IT Project? How about an ERMS (electronic records management system) or a public safety CAD (computer aided dispatch) system?
In my opinion, these are clearly not IT projects. IT should be involved to the extent that they provide a platform, infrastructure and ensure compliance with organizational standards, but getting IT involved with issues of design and workflow can lead to a disaster.
How about a VoIP system? That’s slightly more complicated, but the features and functionality of such a system have a significant impact on end users. Without user input when developing requirements, it is unlikely that the system will fully meet the customer’s business requirements.
Is network infrastructure an IT project? If there actually were such a thing as an IT project, network infrastructure might just be such a project. However, there are only business projects. Even infrastructure projects must address the needs of the business as defined by the users who execute the processes.
Leave IT to the experts
There is a paternalistic tendency of many in our industry to say “We know what you need. Leave it to the experts.” The finest managers, consultants and analysts I have observed are Socratic in their methods. They assume nothing and ask questions rather than make pronouncements. Assuming they know what users need is certainly one of the deadly sins of IT Directors and CIOs.
A philosophical approach is especially important when organizational managers insist on asking the wrong questions. One example is where the management asks “Which ERP should we buy?” rather than asking “What should our business processes look like?” The first question depends on a priori assumptions and is likely to lead to a suboptimal solution or an outright failure. Pursuing the second question with a disciplined approach is likely to produce significant improvements in business operations, but it requires a great deal more work.
Product vs. process
The notion that a product will magically solve business problems is as popular as it is preposterous. One can’t blame vendors for marketing their product as the prescription for all business ills, but one can blame managers and CIOs for believing such hogwash. This tends to be the most difficult conversation I have with clients. They want to buy a product, as if it is a simple choice between a Subaru and a Toyota. What they don’t want to hear is: “We need to take a close look at all your business processes and evaluate your assumptions,” but this is what should occur before evaluating software.
It’s not about IT and not about buying a product. It’s all about your business processes. Focus on business processes and when the time comes to apply technology, you’ll get it right.
© Copyright Jeffrey Morgan, 2016
This article first appeared on CIO.COM at http://www.cio.com/article/3128242/leadership-management/on-the-nature-of-it-projects.html
by 
Recent Comments