Monthly Archives: October 2014

Corporate Non-Profits

We hear a lot in recent years about the changing nature of work and employment– notions of serial jobs, multiple careers, flat and networked organizations, the information or idea economy, the notion that our industrial-era model of factory work is no longer appropriate, the structureless organization model of Valve, etc.

How are non-profits responding to these forces? Are they being embraced? Are they saying “Wow– we’ve always been models for organizational change”?

I don’t think so. The mantra for some time among non-profit leaders has been to become more “business-like.” Which often means formal structures with layers of hierarchy and factory-style bureaucracy.

In other words, the “corporate non-profit” model.

I’m not sure that’s a good model. But I also don’t see any significant disruptive force emerging that can help change that. Is there an opportunity there?


Practical Considerations for IT Structure

Technology, in particular data management systems, continue to go about rapid and dramatic changes. For many non-profit agencies and small, mission-conscious businesses, the task of keeping current with the changing tech environment is daunting especially given the common lack of adequate tech skills and resources.

Some of the key factors and changes include a continuing shift of emphasis on outcomes and performance management instead of output measures; the ascendancy of mobile computing and bring-your-own-device approaches; the “Internet of Things” meme; and huge advances in robotics, artificial or machine intelligence, and virtual reality platforms. For many in the non-profit world, those changes are interesting but can seem to have little practical application to day-to-day operations. And when they are perceived as applicable, their actual effective implementation appears to be far beyond the local operational grasp.

But those changes are central to the fundamental shift in global economies away from the industrial age and its focus on labor and capital to an information or ideas age that focuses on data, information, knowledge, creativity. So how can non-profits cope with those changes?

I don’t have a unified, overall approach to that but am beginning to see some of the pieces and considerations.  First, the new world of technology and data does not require a huge refresh of either software or hardware. That means that any organization with a basic IT infrastructure (i.e., desktops and laptops joined in a local network and with widely available Internet access) can leverage that infrastructure to the new world.

Much of the recent shift has involved “The Cloud”– from cloud storage to hosted (cloud-based) applications. Connecting a typical desktop or laptop to the Internet and its resources essentially makes that local workstation a “thin client.”  Unlike the traditional thin client (or even VDI) approach championed by Citrix, VMWare, Oracle, etc.,  the new thin client gets its processing power and data from a multitude of servers and providers. Accessing that power and data can be done with simple, inexpensive, or legacy tools. A “general purpose” computer is not needed anymore.

Obviously that approach places increasing emphasis on the access to reliable, adequate connectivity. Google’s experiments with gigabit broadband and national debate about “Net Neutrality” illustrate that connectivity is a major concern in the new tech world.

One implication of the shift to distributed systems, to “small pieces loosely joined” (David Weinberger), is that organizations have to pay more attention to figuring out what pieces and tools should be accessible to various workers. (And then, of course, how those pieces get joined or linked together.) Is it really necessary for every field case manager to have access to the entire electronic service record on their mobile phone or tablet? The challenge becomes finding or building systems that follow the small pieces approach and having the resources to link them together into larger, meaningful and actionable systems.

A major barrier in this new world is the issue of security. In the early days of computing, security was handled by restricting physical access, including keeping systems turned off unless being actively used. That approach worked well in the world of mainframes, mini-computers, PCs, local area networks, and closed wide area networks. But the always on, everything is open and transparent world of the vast and uncontrollable Internet, it becomes harder to use physical or even virtual restrictions.

The challenge of secure computing is probably the biggest issue facing not just non-profit agencies but all users of technology.

Project Management Summary

So I finished my first foray into learning the PMBoK approach to project management and have some more observations.  There’s a lot of detail in the PMBoK method:  4 phases of the life cycle (CDEF), 9 knowledge areas, 5 process groups, 42 distinct processes, 6 constraints.  It’s very complex and, to my simple mind, cumbersome. I prefer simplicity (who doesn’t?).

It seems to me that one way to simplify this beast is to think in terms of three major outputs or documents from the whole process:

  1. Project Charter
  2. Project Management Plan(s)
  3. Project Closure Report

The Project Charter is, of course, the linchpin for the entire process. It defines the overall scope and justification for the project as well as the key players. It is sort of the Declaration of Independence for a project– “we hold these truths….” Without a solid Project Charter, the project will go no where.

Once a Project Charter has been developed and endorsed, all of the project effort is focused on the Project Management Plan (PMP).  First the PMP must be conceived and developed, activities that entail a lot of smaller tasks and processes. Depending on the nature and scope of the project, developing the PMP could be easy and of short duration or difficult involving lots of time and effort. Likewise the initial PMP could be short and simple or long and complex. But like the U.S. Constitution, the PMP provides detail and framework based on the Project Charter and it is subject to amendment and modification as the project proceeds.  When an initial PMP is ready, execution of its contents is conducted with “progressive elaboration.”  That execution ultimately leads to the project’s closure– whether it is successful or not.

Finally, once the project is completed (terminated), a Project Closure Report should be prepared that provides a summary of the project: successes and failures, outcomes achieved, outstanding issues, lessons learned, identified best practices.

It seems that the PMBoK method provides lots of detail on those major pieces of a project, but at heart I think that the Project Charter, the Project Management Plan, and the Project Closure Report represent the foundational structure of successful projects.

PMBoK = Waterfall?

As I’ve been learning about project management, specifically the PMBoK approach, I keep thinking that it seems to describe what in the software world we call the “waterfall method” of software development.

There are lots of examples of the limitations or outright failures of projects following the waterfall method. And there is a healthy group of developers who have adopted alternative approaches such as “agile programming.”

So is there an PMBoK equivalent for agile project management?  One starting point is


Simplify Project Management?

Project management as structured through PMBoK is fairly complex. It involves four phases (concept, develop, execute, finish– CDEF); nine knowledge areas (integration, scope, time, cost, quality, human resources, procurement, communication, risk); forty-two processes broken into five process groups (initiating, planning, executing, monitoring and controlling, closing). Then for each of the 42 processes, detailed  inputs, tools & techniques, and outputs are defined.

Might it be possible to simplify all of that to something like this:

  • Four phases and process groups
    • Concept (Discovery)
    • Develop (Plan, Blueprint)
    • Execute (Build, Test, Monitor)
    • Finish (Deploy, Implement)
  • Six knowledge areas
    • Integration
    • Scope
    • Resources (including human resources, procurement, finances, time)
    • Communication
    • Risk
    • Quality