Since I began this blog I have used it as a means of testing out and sharing ideas about project management, information systems, as well to cover occasional thoughts about music, the arts, and the meaning of wisdom.
My latest hiatus from writing was due to the fact that I was otherwise engaged in a different sort of writing–tech writing–and in exploring some mathematical explorations related to my chosen vocation, aside from running a business and–you know–living life. There are only so many hours in the day. Furthermore, when one writes over time about any one topic it seems that one tends to repeat oneself. I needed to break that cycle so that I could concentrate on bringing something new to the table. After all, it is not as if this blog attracts a massive audience–and purposely so. The topics on which I write are highly specialized and the members of the community that tend to follow this blog and send comments tend to be specialized as well. I air out thoughts here that are sometimes only vaguely conceived so that they can be further refined.
Now that that is out of the way, radio silence is ending until, well, the next contemplation or massive workload that turns into radio silence.
Over the past couple of months I’ve done quite a bit of traveling, and so have some new perspectives that and trends that I noted and would like to share, and which will be the basis (in all likelihood) of future, more in depth posts. But here is a list that I have compiled:
a. The time of niche analytical “tools” as acceptable solutions among forward-leaning businesses and enterprises is quickly drawing to a close. Instead, more comprehensive solutions that integrate data across domains are taking the market and disrupting even large players that have not adapted to this new reality. The economics are too strong to stay with the status quo. In the past the barrier to integration of more diverse and larger sets of data was the high cost of traditional BI with its armies of data engineers and analysts providing marginal value that did not always square with the cost. Now virtually any data can be accessed and visualized. The best solutions, providing pre-built domain knowledge for targeted verticals, are the best and will lead and win the day.
b. Along these same lines, apps and services designed around the bureaucratic end-of-month chart submission process are running into the new paradigm among project management leaders that this cycle is inadequate, inefficient, and ineffective. The incentives are changing to reward actual project management in lieu of project administration. The core fallacy of apps that provide standard charts based solely on user’s perceptions of looking at data is that they assume that the PM domain knows what it needs to see. The new paradigm is instead to provide a range of options based on the knowledge that can be derived from data. Thus, while the options in the new solutions provide the standard charts and reports that have always informed management, KDD (knowledge discovery in database) principles are opening up new perspectives in understanding project dynamics and behavior.
c. Earned value is *not* the nexus of Integrated Project Management (IPM). I’m sure many of my colleagues in the community will find this statement to be provocative, only because it is what they are thinking but have been hesitant to voice. A big part of their hesitation is that the methodology is always under attack by those who wish to avoid accountability for program performance. Thus, let me make a point about Earned Value Management (EVM) for clarity–it is an essential methodology in assessing project performance and the probability of meeting the constraints of the project budget. It also contributes data essential to project predictive analytics. What the data shows from a series of DoD studies (currently sadly unpublished), however, is that it is planning (via a Integrated Master Plan) and scheduling (via an Integrated Master Schedule) that first ties together the essential elements of the project, and will record the baking in of risk within the project. Risk manifested in poorly tying contract requirements, technical performance measures, and milestones to the plan, and then manifested in poor execution will first be recorded in schedule (time-based) performance. This is especially true for firms that apply resource-loading in their schedules. By the time this risk translates and is recorded in EVM metrics, the project management team is performing risk handling and mitigation to blunt the impact on the performance management baseline (the money). So this still raises the question: what is IPM? I have a few ideas and will share those in other posts.
d. Along these lines, there is a need for a Schedule (IMS) Gold Card that provides the essential basis of measurement of programmatic risk during project execution. I am currently constructing one with collaboration and will put out a few ideas.
e. Finally, there is still room for a lot of improvement in project management. For all of the gurus, methodologies, consultants, body shops, and tools that are out there, according to PMI, more than a third of projects fail to meet project goals, almost half to meet budget expectations, less than half finished on time, and almost half experienced scope creep, which, I suspect, probably caused “failure” to be redefined and under-reported in their figures. The assessment for IT projects is also consistent with this report, with CIO.com reporting that more than half of IT projects fail in terms of meeting performance, cost, and schedule goals. From my own experience and those of my colleagues, the need to solve the standard 20-30% slippage in schedule and similar overrun in costs is an old refrain. So too is the frustration that it need take 23 years to deploy a new aircraft. A .5 CPI and SPI (to use EVM terminology) is not an indicator of success. What this indicates, instead, is that there need to be some adjustments and improvements in how we do business. The first would be to adjust incentives to encourage and reward the identification of risk in project performance. The second is to deploy solutions that effectively access and provide information to the project team that enable them to address risk. As with all of the points noted in this post, I have some other ideas in this area that I will share in future posts.
Onward and upward.