In my previous post, I focused on Program and Project Management in the Public Interest, and the characteristics of its environment, especially from the perspective of the government program and acquisition disciplines. The purpose of this exploration is to lay the groundwork for understanding the future of program management—and the resulting technological and organizational challenges that are required to support that change.
The next part of this exploration is to define the motivations, characteristics, and disciplines of private industry equivalencies. Here there are commonalities, but also significant differences, that relate to the relationship and interplay between public investment, policy and acquisition, and private business interests.
Risk
Shake it Out – Embracing the Future in Program Management – Part One: Program and Project Management in the Public Interest
I heard the song from which I derived the title to this post sung by Florence and the Machine and was inspired to sit down and write about what I see as the future in program management.
Thus, my blogging radio silence has ended as I begin to process and share my observations and essential achievements over the last couple of years.
My company—the conduit that provides the insights I share here—is SNA Software LLC. We are a small, veteran-owned company and we specialize in data capture, transformation, contextualization and visualization. We do it in a way that removes significant effort in these processes, ensures reliability and trust, to incorporate off-the-shelf functionality that provides insight, and empowers the user by leveraging the power of open systems, especially in program and project management.
Program and Project Management in the Public Interest
There are two aspects to the business world that we inhabit: commercial and government; both, however, usually relate to some aspect of the public interest, which is our forte.
There are also two concepts about this subject to unpack.
(more…)River Deep, Mountain High — A Matrix of Project Data
Been attending conferences and meetings of late and came upon a discussion of the means of reducing data streams while leveraging Moore’s Law to provide more, better data. During a discussion with colleagues over lunch they asked if asking for more detailed data would provide greater insight. This led to a discussion of the qualitative differences in data depending on what information is being sought. My response to more detailed data was to respond: “well there has to be a pony in there somewhere.” This was greeted by laughter, but then I finished the point: more detailed data doesn’t necessarily yield greater insight (though it could and only actually looking at it will tell you that, particularly in applying the principle of KDD). But more detailed data that is based on a hierarchical structure will, at the least, provide greater reliability and pinpoint areas of intersection to detect areas of risk manifestation that is otherwise averaged out–and therefore hidden–at the summary levels.
(more…)Mo’Better Risk — Tournaments and Games of Failure Part II
My last post discussed economic tournaments and games of failure in how they describe the success and failure of companies, with a comic example for IT start-up companies. Glen Alleman at his Herding Cats blog has a more serious response in handily rebutting those who believe that #NoEstimates, Lean, Agile, and other cult-like fads can overcome the bottom line, that is, apply a method to reduce inherent risk and drive success. As Glen writes:
“It’s about the money. It’s always about the money. Many want it to be about them or their colleagues, or the work environment, or the learning opportunities, or the self actualization.” — Glen Alleman, Herding Cats(more…)
I Can’t Get No (Satisfaction) — When Software Tools Go Bad
Another article I came across a couple of weeks ago that my schedule prevented me from highlighting was by Michelle Symonds at PM Hut entitled “5 Tell-Tale Signs That You Need a Better Project Management Tool.” According to Ms. Symonds, among these signs are:
a. Additional tools are needed to achieve the intended functionality apart from the core application;
b. Technical support is poor or nonexistent;
c. Personnel in the organization still rely on spreadsheets to extend the functionality of the application;
d. Training on the tool takes more time than training the job;
e. The software tool adds work instead of augmenting or facilitating the achievement of work.
(more…)
Life, Project Management, and Everything 