By Dennis D. McDonald

This morning while scanning my Google+ feed I saw a link to an old (from 2008) article titled “Why project managers get no respect” by Scott Berkun. It’s an interesting read about things I had never been aware of or had forgotten.

Having been in the project management business since graduate school I’ve often served in an intermediary position between IT and business types. I “get” the traditional mistrust between the two groups (and with “project managers”) that sometimes surfaces. I also remember early on realizing that the IT folks in client companies tended to be the ones who really understood the basics of disciplined project management.

Here’s the comment I left on Berkun’s article:

One of the mistakes people often make when discussing project management in the context of software and tech is to overemphasize the importance of the development process, software development in particular. In my experience, tech oriented projects in general and software “development” projects in particular need to address both communication and collaboration both inside and outside the development team. Yes, you want to enable developers to do what they do best but you also want to make sure what they do is contributing to the client’s or the customer’s goals. This is easier in smaller projects and smaller organizations but as size and complexity grow project success and value are increasingly dependent on non-technical considerations. That’s where the project manager’s focus should, not on micromanaging the developers.

Related to this, a couple of weeks ago I attended a meeting of the US Department of Commerce’s Data Advisory Council where representatives of 18F,  an Agile-friendly developer group out of GSA, described what they saw as basic and necessary to project success; according to 18F, they turn down projects where these two things are lacking:

• Well-defined statements of work.
• Commitment of the client agency’s senior staff to availability and collaboration.

These are two of the most important “classic” project management success elements in just about every discussion of the differences between successful and unsuccessful projects. Hearing support for them from the perspective of uber-cool 18F was satisfying.

Still, the issue of mistrust (or to be less apocalyptic, miscommunication) between business and IT types over project management may be getting worse, not better. Anecdotally I see evidence of this worsening situation in two possible areas:

1. IT departments no longer having sole authority over tech projects.
2. The increasing visibility of “data” as a resource that needs to be managed — and the shortage of tech and non-tech managers with data skills.

The first is due partly to the lowered “barriers to entry” for using IT resources to solve problems. Consumer tech is cheap, accessible, and can be manipulated by non-programmers. Cloud vendors provide resources for hire that were previously only available from central IT. The result: end-runs around IT occur in the name of speed, agility, and innovation. The downside: failure to manageIT resources strategically can generate waste, overlap, and lack of support and sustainability.

The second issue is more complex. It concerns the shortage of both technical and analytical staff with experience in big data tools and techniques. While it is true that “big data” has fallen off the Gartner “hype cycle,” interest in doing a better job of applying better data and analytics to both tactical and strategic decisionmaking are still focusing a lot of attention on tool availability, hiring, and how management can (or should) do a better job of aligining data resources with corporate goals and objectives.

For this “alignment” to take place we need not only staff skilled in data but managers who understand data and the management of data related resources. I’ve written about this need for management skills regarding governmental open data efforts but the need may be even larger for managing “big data” efforts more generally.

Which brings us back to the “project management” skills needed for managing data intensive projects. When you read about “big data” in the tech press you seldom read about management and governance issues (though there are some really serious examples that should receive more attention, such as the initial problems with the Affordable Care Act web site). The initial problems there, it seems, were related to management and communication which in turn led to serious within-application integration issues.

But these days, still, when you read about big data or if you attend conferences or webinars you’re much more likely to read about products and tools. You don’t hear as much about “back room” management issues you need to address to make sure all the members of the project team are sharing information and marching in the same direction.

A lot of this understandable given the drive to sell and license software and cloud services. But let’s remember the basics of project management. Otherwise we’re going to be wasting a lot of money on irrelevant analyses, elegant but useless models — and web sites that don’t work.

Copyright (c) 2015 by Dennis D. McDonald. For articles like this scroll down. For information about my consulting go here.