Containers - Back to the Future of Software Development Yet Again

A new concept of "containers" promises to make software applications free-standing entities, essentially infrastructure-independent.



H/T to Federal Computing Weekly (FCW) for a good overview post on this concept and some thoughts on the challenges with implementing it.

This concept makes sense.  But we've heard this song before:

• Object-oriented programming was supposed to shred everything down to micro-applications that could just be recombined to make full-sized applications
• Services-Oriented Architecture (SOA) was supposed to shred everything down to micro-services that could just be recombined under a thin execution logic layer to make full-sized applications
• Virtualization was supposed to separate systems into n-tier architectures so that the applications could be treated as black boxes and shifted from one infrastructure to another.

Issued raised in the article include:

• Container realization software is still new and changing rapidly.  That poses all sorts of complications if the goal is stability, and might cause rework of the applications to stay compatible with their own platforms.
•  Once it goes into production, many applications depend on it (or at least that is the idea).  How do you make sure nobody fixes it, or amends it to suit a new applications, without validating the impacts on all the application?

This is not the first time we've heard those concerns raised, either, so maybe we have a better idea today on how to solve them.

So what is different about the new containers?
Your observations are very welcome!

While you're here: I's super-pumped for the pending release (October) of:
Let It Simmer: Making Project, Portfolio and Program Management Practices Stick in a Skeptical Organization.  Take a peek!


Photo credit: "Mülltrennung" by Peng 6 July 2005 16:28 (UTC) - --Peng 6 July 2005 16:28 (UTC). Licensed under CC BY-SA 3.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:M%C3%BClltrennung.jpg#/media/File:M%C3%BClltrennung.jpg

Can a Charter Drive Project and Program Success?

Every methodology tells you to start by securing executive support, as demonstrated by getting a signed charter.

That's a good idea, although not because anybody is actually going to pay attention to the charter document itself.  Most likely the only time it will be used as a reference is when stakeholders cheerfully point out that whatever you are trying to accomplish is not specifically included in the charter and most regretfully they don't have the resources at this time.  

It takes time and effort to get a charter signed out.

It is also true that a number of successful projects did not actually have signed charters.  So why bother?

Successful initiatives without formal charters achieve their success because they have active, observable leadership support.  Leaders are constantly inquiring after its health and come down like a ton of bricks if resources are not available as and when needed.   When that's happening, the document is of little need.  At the project manager level, the sure knowledge that if the obstacle is not cleared away then Mr. Big will apply his own unique problem-solving techniques is by itself a sufficient motivator that problems get resolved.

You cannot play that card too often, and you cannot pull it on every initiative, or you are back to the chaos of not having any priorities at all.

The point is not really to get the charter signed.  The point is that if you can't seem to get to closure to get the charter signed, then your initiative obviously doesn't enjoy a great deal of status with the intended sponsors.   If they won't do something as simple as signing the charter, do you really think they will go to war with the other senior players when they renege on their resource commitments? 

In Japan, executives may even sign it upside down to indicate that they don't really support it but they won't oppose it either.  Sometimes it would be helpful to have it right out on the table like that!

Having a charter does not prove that you have support.

Being unable to get a charter means that you certainly do not have support.

So by all means get a charter.  It won't prove that they really care, and it does not mean that you will actually get all the support that is promised.  At least it shows that they don't really hate the idea.

Learn more about charters in "Let It Simmer: Making Project, Portfolio and Program Management Practices Stick in a Skeptical Organization" will be out at the start of October.  Check it out at www.simmer-system.com and get in position for a pre-order at the lowest possible price!

Hidden Features of Windows 10 Install That You Should Worry About and Fix

There is a new "feature" in Windows 10 that you'll want to know abut (and fix) on Day One.  That's on top of the little security challenge noted in the previous post which notes a key action you will need to take before the roll-out happens.  If you haven't done it yet, please do so immediately.

A separate post addresses the actual roll-out experience, but the summary is: pretty painless.

What I want to let you know about today is a whole new security wrinkle you need to consider: the Windows 10 defaults.

Yup, that's a vulture sitting there, looking over your shoulder.


(Image: Audubon)

Let me say first, and not for the first time, that I am a Microsoftie at heart. And I trust the NSA with my information a heck of a lot more than I would trust the Washington Post (in case you are reading this, hi guys!)

Still, you can't help but be surprised by the default settings.  They go a long way to explain Rand Paul's apparent paranoia.  If someone really is watching your every move, are you really paranoid?

So, when the actual install cycles end and the system asks whether you want to customize: YES, you do!

Read the settings carefully. Your choices may be a bit more aggressive or cautious than mine for various reasons.

Here are the ones that jumped out at me:

In the basic Customization table, the key settings are almost the reverse of what I wanted.  I disabled:

• Content and calculation details: no, Microsoft does not need to know that
• Typing data: ditto
• Advertiser information: no, thanks.  I get enough of that already.
• Location (since this computer doesn't travel much and when it does I use the phone for "near me" sorts of things). Google seems to know the answer anyway; that's probably a whole other topic!
• Page prediction. This one is not so much a security and privacy issue as it does cut down the background processing.  Yes, it probably would speed up the actual transition from on page to another but Verizon's FIOS service and (let's admit it)Windows 10 are pretty fast for most purposes.
• Suggested hot-spots: more ads
• Auto-connect to content-suggested networks: Really?  "Yes" by default?

That is 8 out of 10 that I chose to reverse.  What is left?

• Smart scanning: protects against known or likely threats while in Windows browser: seems like a good idea, although I will likely not be using Windows Edge until all the sites that don't support Internet Explorer reverse themselves.
• Send errors and diagnostics to Microsoft: sure, let them identify and fix problems. Of couse, I have no idea how much data gets sucked out of the machine when i doe that, and it may well undo all of the concerns noted above.  Oh, well.

After the customization appears, you will get an opportunity to go through the "Getting Started" page. At first I thought it did not work, but it came to life eventually.  Then I thought that the audio drivers has been killed, as the getting started videos were playing but without sound.  That too was restored after a bit.  I suspect that the system was busy finishing up some other tasks in background.

The system now advises that it includes several new applications:

• Photos (the old Microsoft Office Photo Manager turned into a tile; actually this happened in Windows 8)
• Music (I can't help you much here as I don't have much to do with music)
• Microsoft Edge (new new name for the browser), and
• Movies and TV (Windows Media Manager turned into a tablet app)

Since they are tablet-style applications, if you haven't had this pleasure before you'll have to get used to dragging them down and off the screen when you are done with them.  Yecch.  And it makes it quite hard to multitask with them, i.e to have them and another applications on the screen at the same time. There's probably a way to do that but frankly nothing about tile-world is intuitive to me and for the most part it disgusts me so much that I just don't use the apps.  There's a reason why I have a PC as well as a phone, which is specifically that I want to to be able to use information from more than one program at a time.  I assume that was also the reason hardly anybody liked Windows 8 either.

Once you've registered changes to your defaults and taken about 10 minutes to go through the Get Started set of tutorials (they are pretty lean, and more motivational than instructional, so it does not take long), you get a restart.

Up comes a nice new screen and to my surprise the system displays some customer screen-savers you may have saved earlier rather than the standard Windows displays.  Thus far, AVG Tune-up has not complained of the dag on system resources that those screen-savers cause.  When it does, Windows has some defaults available.

Also, fortunately, the Microsoft ID (the outlook.com address you were forced to create is you bought a computer with Windows 8 on it) and the PIN you had to set up for Windows 8 still work.

Then the system will take another recycle for applications setup; this one is only about 5 minutes.

Once it has finished with that, you get the opportunity to do more customization and again you may want to do just that.

The next area with some security implications is the Notifications.

• Tips about Windows: You may want to shift this to "on" for a while until you get the feel of your new toy.  You can get back to the notifications dialogue from the Start menu [did I tell you that as back?  Thank goodness it is.  Although you may want to consider re-installing your own, as the Windows 10 version still does not show Recent History].
• Application notification: Of course yes. You should decide on this at the application level.
• Notifications on the lock screen: The point of the lock is that you are away from the computer. Why show your notifications to anyone else?
• Alarms, reminders and incoming VIP call while locked: same reasoning
• Hide notifications while presenting: yes, that would be a good idea. You cannot rely on this, however, as I assume it only works if you have a projector plugged in, or perhaps if you are using PowerPoint.  So if you are doing a webinar-type event through a web service, it may or may not pick up on that. If you're going to share your desktop, you should assume that people will see what you have on your desktop.

There are other settings but they are pretty much the usual choices, with one exception: under Multi-tasking, there are "Virtual desktop" options for showing desktops other than yours.  Whether you want to do that or not depends on your situation, of course, but there is no provision for declining to show your desktop to anyone else.  Until I learn more about how this works (as usual, there is zero documentation for the system), I am going to assume that anyone in your connected work-group can see your desktop.  And of course the people in Redmond, if you did not turn off the customizations noted above!  And the NSA.  And the Chinese.  Well, heck, you might as well not worry about it.  Just stay off the porn sites.

That's about it from a security perspective - as far as I know!

Microsoft seems to have a bit better information as there has been a patch install daily so far. Presumably they are fixing holes.

Oh, yes: one more thing.  When all this is done, if you have not done so already, check the "hidden icons" tray.  It's in the status bar at the bottom-right of the screen.   If your antivirus of choice is not up and running, then you'll need to decide whether to adopt Windows Defender or go back and re-install your preferred flavor. Which is where the "key step" from before the install comes in.

As always, comments are welcome.

How to Survive the Transition to Windows 10 - Fact versus Fiction

Well, the great day has finally arrived.  Or maybe not.
All of us will have the opportunity to see one of the most amazing projects of our time as it unfolds.
Microsoft is going to replace the operating system on hundreds of millions of computers with basically no user involvement needed.  Hopefully.

Naturally they have a story as to how this will work: here's a link to their FAQ page.  It's pretty detailed and informative.  Still it is what architects cal this the "rosy path" - everything goes as planned.
I never did get the Apple craze, I guess I'm just a Microsoft sort of person.  So I hope it does go well.  This post will be the first of several that comment on what really happens.

Everybody will be working through this at a different pace.
If you have any insights to share, please do comment and it will become part of the thread.
If you have a lot of knowledge to share, let's talk offline about a guest post or a webinar.

The announcement

Some months back, Microsoft advised me that I would be getting Windows 10.  I needed to sign up for the deferred program or else it might just appear right now.  Well, duh.  Of course I am going to wait until I learn more about this beast. It was hard enough trying to get past Windows 8 and keep using Windows 7.

I still haven't learned how to use Windows 8, nor have I figured out why anybody would want to.  The whole point of Windows computers is to do useful things on them , which usually requires more than one window being open, and that is something you cannot in Tile-world.  Apparently nobody else figured it out either, hence the arrival of Windows 10, with, we are assured, much more customer validation and totally complete testing. Hopefully I learn to love it.

The deferral process required a small download to my system.  Did I trust that?  Since they built about 4 GB of code that already sits on my machine now, and I get who knows how many updates a week in the background, of course yes.  If they were going to attack my system, it would have been done long ago. The little app sat quietly in some corner waiting for its master to awaken it, with no apparent impact on the system at all.

The Prelaunch

This week I received a popup notification that the window for Windows 10 downloads is now open.  There is a phased roll-out.  It does not say which phase I am in.  I hope I am last.

Even the deferred program has a deferral option.  I can even choose not to get it, and stay on Windows 7. If I get it and do not like it, I can roll back to Windows 7.  However, if I do that, I'm on my own, and I will have to pay market price for Windows 10 once I realize what a terrible mistake I made.  But I could go ahead and do it (or, really, not do it).

As it happened I went by a Microsoft store where I met a very knowledgeable representative.  He says they have really tested it a lot. There have been very few complaints about apps not working, although it is true that for some that come in OS-specific versions, it may be necessary to get the Windows 10 drivers, plugins or whatever from the application vendor.

One of the features of Windows 10 that he showed me is that tile-world does not occupy the entire screen, so you can get at the rest of the screen without having to shut down your current app.  So you can in fact work with two applications open at once, even in Tile mode.  That is great because .some of the Windows tile-based apps are really pretty nice but until now I have never used them because of the one-app-at-a-time approach.  Now maybe I can use them.

What Do I Do Right Now?

Go through your Control Panel and work out what applications you have installed.  I have at least four that I don't remember what the heck they were and had to go to the internet to find out.  If you don't need them any more, get rid of them altogether. If you do need them, write down your license keys, user ID and password for each app that you use, and keep it somewhere other than your computer - just in case.

Updated: after the install did upload itself, most of the major applications seemed to be in order. There are some that Windows removed altogether, which revealed themselves fairly quickly in normal operations because they were mostly freeware that supplements the Windows capability (or, perhaps, turns it back to the way Windows 2000 did it - old fuddy-duddy!)  Examples include Classic Shell (the Start button tool) and 7-zip (zip compression utility that didn't collapse the way the Windows 7/8 versions did).

The most serious problem was the disappearance of AVG (various security packages). Microsoft understandably inserts Windows Defender as a default to make sure that the user has some security present, but did you really have blow the other package away without a trace?

Since I use the paid version rather than the free version, it was a good thing I had the e-mails with the key codes. I do note, though, that if you have forgotten to record your keys, AVG will send them to the e-mail address from which you purchased the licenses in the first lace.  And if you have any of your AVG keys then you can access your AVG account and get the rest of them.

In a separate post I will go over some of the installation quirks.  There are not that many, but what you find may surprise you.

I have no doubt whatever that many people are more knowledgeable than me on this topic.  Please leave comments!!

LeSS SAFe is more - events coming up right now

Another installment looking at different ways to adapt Agile to enterprise scale.  Inflating it, as it were ...





Photo credit: Gerald Pereira and License

• First, some comments on LeSS given that you have the opportunity to go see for yourself (if you can afford it).
• Then opportunities to learn about SAFe.

What is with these mixed-case acronyms?  I guess there are some people pedantic enough to complain that you cannot use a capital E in SAFE because the words has a lower-case "e".  It would be if we YELLED IT LOUD ENOUGH :-)
Worrying about that sort of thing is very un-Agile.

LeSS Materials and events

H/T to Brian Sjoberg at Excella Consulting (a company that has impressed me over the past 2 years), although in this case Brian is representing the DC Scrum Users Group (DCSUG)for this heads-up.  If you have interest in Agile I can thoroughly recommend DSUG's meetups.

• A course on Large-Scale Scrum (LeSS)in the DC area from August 10-12 (registration page)
• LeSS SAFe Comparison by Gosei
• Blog post comparing Waterfall, SCRUM, SAFe and LeSS here.

LeSS Seems to be Just Less

As noted in an earlier post, I have not quite got the drift of LeSS.

The folks who are leading proponents of it in the US describe the integrative processes as "whatever the self-defining teams define it to be".  One could make a case that a pyramiding schema of scrum-of-scrums and product owners would be able to establish integration in terms of cross-component integration.   I don't see that as alleviating the organization's concerns over scalability and security.

I do note that in the most recent framework picture (at the LeSS link above), architecture and security now have a specific place.

A Turn for SAFe

H/T here to Net Objectives for the following information:

• Conference: Agile2015, in Washington DC - next week (August 3-7).  $2400.

• Net Objectives' 3rd Day of SAFe: Elaborating SAFe  (you have to give up your e-mail address but it gets you access to tones of material).

• SAFe in an Hour. A quick introduction to SAFe.

• Driving from Business Value in SAFe. Introducing minimum business increments and why they improve SAFe's portfolio management.

• Rapid Implementation of SAFe. Rapid is the new method we'll be discussing in the open space.  This was a pre-look at it. 

• Introducing Leanban. A first look at our new team-level Agile process that is more than an integration of Scrum and Kanban. [This link here is further updated since the presentation date].

• Using SAFe in Small & Mid-Scale Organizations. SAFe is intended for development groups of more than 50 people.  This webinar presents methods of coordinating multiple teams which total fewer than the 50 required for SAFe.

Agile Enthusiasts and Professionals

Beware the agile enthusiast who has only worked on one project at a time and does not get why the enterprise doesn't get Agile. Enterprise Agile often fails because Agile enthusiasts do not really understand it either.

I distinguish here "agile enthusiasts" from true agilist professionals who absolutely do get the issues around Agile at scale, indeed I defer absolutely to their vast experience.  You know who they are.  I hope not to offend the many others who fall into that category by naming those I've had the most interaction with and therefore admire tremendously include David Anderson, Ron Jeffries and Jeff Sutherland.   How do you tell the enthusiast from the true professionals? Ask them a couple of questions:

Where did the money came from to do their agile project in the first place? Where did the themes and epics came from?  Do we really rely solely on the product manager's brilliance? Where did the networks come from that you're going to build your solution on? Deer in the headlights [sorry for not attributing, but the hosting page didn't either].

The question isn't really why enterprises won't adopt agile; the real question is why agile enthusiasts don't understand some key things:

• the processes at work in their own enterprise
• how their projects came to be in the first place
• how to fit their little piece of the world into a bigger picture. 

Here's a post that explains how Agile fits very well into the enterprise - if you understand how both of them work. Understanding one and not the other leads to misunderstandings and outright hostility.  Not unlike the rest of the world.

They are  not alone, of course; lots of people on the more traditional side of project, portfolio and program management don't understand it either.  Which is why I write this blog.

Agile artifacts - low-tech solutions in a high-tech field

Isn't it ironic that Agile is the latest thing used to drive our most high-tech field but it seems to be most effective to carry it out using really old-school tools: wallboards and spreadsheets.



I would have started with the credit for the inspiration but it wouldn't have made a very appealing thumbnail on Linked-In or Google. This post was inspired by a tweet from Andrew Yochum (@Yochum) which in turn leads to a blog posting which is absolutely the least self-promotional ever -- no author credits anywhere. So now you have his Twitter information and a link to the post . As you will see from the link, I used his kanban picture too, as that helps to drive readership, but since I'm promoting his post that seems fair.

Back to the topic: I've taken a look at several automated tools that support Agile processes (Rally, Mingle, Jira) and they all have the same weakness: real estate.   Unless you have a humongous monitor, it's pretty hard to see what's going on in a screen-rendered version of the wallboard, and if the metaphor converts everything to lists then at least for me the whole flavor of Agile is lost.

So what about the low-tech options?

I've used SharePoint to try and track stories and progress.  It works, after a fashion.  It has the advantage over Excel in that everyone can see it and work on it at the same time.  The disadvantage is that you can't see the cards laid out; you have to use each story as an item in a list.  By creating the progress points as discrete options in a single column (fields), you can get SharePoint to generate views, using the list-type format and the power of the "group by" function, to show you such information as:
You can also use the calculation function (sum) to show you the number of story points planned and completed in each sprint, and that of course is the information you need to construct velocity charts - in Excel!

Excel, of course, lends itself to the charting.  It is also very handy for tracking the stories in the form of a requirements matrix (I know the purists are gagging, stop that).

What about using the Excel as the board itself?   No problem!  With its columns-and-rows display, Excel is of course capable of acting as the board.  In fact, in the example shown above, we could and did extend the columns to the right because we are tracking the stories anyway). But it gets to be a pretty big sheet.  For group purposes, Excel's drawbacks as the primary tool is that only one person can edit it at a time and it must be maintained on a shared drive, which means everyone must have access to that drive. For some reason office shared drives seem to be a bit more persnickety than things hat live on a web site if you're coming to them remotely.  And of course Excel doesn't do versions, so if one person trashes up the sheet the only way to fix it is go back to the last version that was saved separately.

And of course there is the wallboard. The problem with that is the demise of the concept "wall".  With open-plan offices increasingly the rage, there are no walls. Withe remote workers, there is nobody there to look at the wall anyway.  And people seem to get upset if they have the work-space right next to a spot (e.g a space along one of the rare walls) where a half-dozen people will cluster and jabber, even if it is work-related.

In a related post on Linked-In Pulse, I also note that the same problem arises with the traditional waterfall tool (MS-Project).

Please feel free to share your workarounds for using electronic methods of replicating a physical collaboration that hardly exists in the real world any more.

Scrum as a Teenager: A Retrospective from Jeff Sutherland

Getting to Done

This post is a summary of Jeff Sutherland's presentation to the DC Scrum Users Group, 21 May 2015.
The slide deck is available at Jeff's company's website.
The entire presentation can be seen on the DC Scrum Users Group Meetup site which may require you to join the group, as well you should if you are in the DC area and interested in Scrum.

Reminder: the goal of Scrum is to produce working software at the end of each sprint.

The Agile Manifesto did not spring from the blue.  The group drew its conclusions from over 20 years' of data compiled by Bell Laboratories. Those records showed conclusively that:

• Communications drive production effectiveness
• Specialization cripples production

Quite aside from the speed aspect, the data also showed  (and current data continues to show) that a bug (or failed test) that escapes from a sprint costs 24x the original development effort and time to find it and fix it.  Keep track of these events is important: in his experience, as soon as management get hard data on it, the problem of whether software needs to work at the end of a sprint is dealt with immediately.

Jeff provided references to a second data source (the Chaos Manifesto) which found that the long-standing problem with delivery of IT projects documented by the  Standish Group over the years has not changed much for Scrum-managed projects.

He also noted that for small projects, waterfall is just about as effective as Agile, probably because the timing and scope don't offer much risk anyway.

What are the blockers to success with Agile?  Success being defined as ready and done.

• Teams trying to drive features out at maximum velocity are buried in technical debt.  You can't dig your way out of that hole with continuous improvement efforts later on.
• There is organizational debt.  This is what Kik Piney calls "anti-maturity"; you can learn more about it in this post. 
• Organizations are stuck in "old way" thinking: press the developers harder, and compile more reports.

How bad is it?  At Microsoft, as much as 85% of the effort is classified as "non-tool" (a euphemism for "rework").  But at least they have recognized it and are doing something about it.  Something quite scary-sounding, in fact: they are abolishing all testing outside the main sprints. [Audience gasps]. At Nokia, the company's Agile process got so bureaucratic they were completely unable to react to the invention of the smartphone.  Ironically, Microsoft returns to the story - it bought Nokia and killed off the company.

Some bad news for those consultants who have gone in on the credential mania: Silicon Valley is now divesting itself of Agile Coaches, replacing them with internal assets because they already understand how the company actually works and they can be held accountable to deliver working software.

One of the big new topics is Agile at  Scale.  The consensus seems to be that it does not work.  That isn't really true.  Consider the Internet itself, the world's largest and longest Agile effort! Scaling Agile and Scrum, like the one-project versions, depends heavily on competence for success. It is best done by scaling out, not up, though coordination rather than developing policies.  Consider the 24-hour car-building project.

So why are we not getting to done?

• Done is not well-defined.  Done must include "working".  Product owners are sometimes pressured to accept work that is not truly done in order to maintain an appearance of "no problems".  That's not the point of Agile. Accepting incomplete work also provides a distorted view of velocity (well, that is rather the point, isn't it) that just makes subsequent estimates even worse.
• Stories are not ready.  Estimates are bad; stories are not broken down to minimal bites.  Failing to understand true velocity causes the team to take on too much work, and then they just start shaving the work even more. 
• Dysfunctional leadership.  Often, they can't stick with their priorities long enough to get through a sprint.  Worse, when things run into issues, they are willing to paper over it to provide the illusion of velocity for reporting purposes.
• Technical debt (already discussed)
• Organizational debt (already mentioned)
• Last but not least, bad Agile Coaching.

What can we do about it?

• Use a defined Scrum model. That would include the definition of done.  If effectively defined, it may not be necessary to test every feature on every build or sprint.
• Have stories ready.  They need to be defined effectively, and trying to get it all done in a few Spring Planning meeting hours is simply not possible.  So you have to front-load that effort.
• Major shifts in the corporate supporting processes.
• Establish goals and work to them
• Establish a viable business plans before starting development
• Remove barriers and wastes
• Hold the Product Owner accountable for the value delivered per story point
• Hold the Scrum Master accountable for ... well, that is the key question.
• Eliminate Technical Debt.
• Identify and fix blocks
• Use cross-functional feature teams
• Train and hire "T-shaped people" - people with the ability to contribute in several areas (wide) and solid skills in one or more particular areas (deep).
• Build out an object-oriented architecture to permit re-use
• Monitor the value streams
• Queues
• Wait status
• Other metrics

This summary didn't capture all of the nuances - many of the pearls are in the one-liners!  See the live presentation, you will enjoy it.

Earned Value EVM and Level of Effort - Yes You Can

Oscar Wilde would have made a great program manager.

"Nowadays, people know the price of everything and the value of nothing" - Oscar Wilde.

We saw in an earlier post that you can do EVM with Fixed Price after all. In a true fixed price contract, the number of resources and working arrangements are not under the buyer's control; the vendor just gets the job done somehow.  You can still work EVM into it (see the prior post at the link above).

It is ironic that so much of the contract work for the government, which advocates very strongly for using EVM has migrated very rapidly from the much-maligned cost basis to LOE. Why is this a problem?  Because it appears to be unaccountable.  The team comes aboard to ... well, to do what?  Whatever needs to be done, meaning whatever the contract monitor wants done, which of course is a personal services contract and would therefore be illegal (in government), which no doubt explains why so many of them are in place in Washington.  But there they are, and we have to deal with it.

People think you cannot use EVM with LOE because there are no real deliverables and the planned and actual costs are always the same.  The "official" solution is that level-of-effort activities don't contribute to specific work packages and should be held in a separate line of accounting from the work packages.  Then they just accrue costs as the calendar passes; but they do not earn value. They are part of the project cost baseline but not the performance baseline. This is a good way to account for project-wide overhead costs, which contribute more or less equally to all ongoing work packages (or impede them, depending on your point of view!)

What happens if the level-of-effort people are working on the actual deliverables?  You can't exempt 95% of the project labor from the EVM metrics.  For true LOE contracts, whether on their face or disguised as fixed-price contracts, the people just show up to work ... and do what?.  Since it is illegal to award an actual personal services contract, you don't often see one that actually says "just give us xx bodies and we'll tell them what to do". What you see instead is a "fixed price" contract that is really level-of-effort: the vendor is to deliver a defined number of hours (conveniently 1980) of various labor categories, with a statement of work that is either very vague or quite specific but will be completely ignored.

At a very basic level, if the vendor fails to provide the agreed resources (a common occurrence), then you can show a delta between planned cost and actual cost.  The philosophical problem here is that no backlog of work builds up: customers may be poorly served at the time, but there is no way to go back and serve them later when the resource does show up.  That, of course, raises the uncomfortable question of what value was lost by the work not done, and if you use that math then you have to extend it to question whether any much more value is gained from the work that was done.

As to the so-called "fixed price" contracts to provide labor-hours, that's no different at all from other cost-based contracts; there's just less paperwork needed to establish the actual cost.  Many contract monitors prefer not to crack the whip, or don't know how, but since it is nothing but a typical cost-based contract you can give guidance on the deliverables to be produced and the hours (costs) needed to do it.  If it gets done sooner or cheaper, you are ahead of the game; if it takes longer or more work, then you are behind the plan.  Voila: we have EVM!

Let's suppose that the contract does provide for a real LOE and real (if vague) deliverables.  The very latest thing in this arena is agile-type work (especially Scrum, the most popular brand) in which a team assembles on a near-full-time basis to do whatever work they can get done to deliver for each sprint.  Despite the popular impression that Agile is just a license to throw all oversight away, there is actually a rich body of knowledge on Agile metrics.  Just as with a true fixed price effort, it is entirely possible to establish intermediate milestones for longer-term efforts (such as a release) in which the earned value might be as simple as a completed sprint and may be more complex to address the planned and actual velocity.  an even more sophistical scoring method can address the velocity at which delivered features are meeting value priorities.

Just as with the true fixed price scenario, the important thing is to separate the concepts of "value" and "cost". 

Earned Value and Fixed Price - Yes You Can.

Earned Value Management is at the core of any project management framework as the method of integrating cost, schedule and scope to assess the progress of a project.  The framework has been remarkably stable over at least the past 40 years, from its earlier incarnation as the Cost/Schedule Status Report (C/SSR), and since it pretty much conforms to common sense [we can talk about Schedule Variance in another post], it is quite likely that the Pharaohs had something similar. Tens of thousands of project managers have been trained in EVM, and it is quite impossible to pass any certification test without knowing at least the basics.  And it is Federal law that any contract over $1 million must be managed using EVM.  Yet at seminar after seminar, certified PMs report that they are not using EVM.  In the public sector it is resisted with a passion that most people had assumed bureaucrats do not possess.

Sure, most people, even trained PMs, and all organizations vastly prefer to evade being held accountable. That's why we need objective reporting systems in the first place.  Let's just deal with the argument that EVM does not apply to fixed-price work (which most Federal contract work is supposed to be) or to level-of-effort work (which almost all Federal contracts are).  Once you take those two approaches off the table, particularly if you buy into the nonsense that a labor-hours contract is "fixed price" because the unit price per hour is fixed, there's not much left. But what "everybody knows" is quite untrue.  Saying that something cannot be done does not really mean that it is impossible, just that you want me to think that it is impossible so I stop asking you to do it..

The argument against using EVM for fixed-price work is that the cost is accrued only at the point that the delivery is completed, at which point the cost is always equal to the negotiated price (unless you are selling airplanes to the Defense Department).  Likewise with level-of-effort work, where people just show up and do whatever the client wants, there is no contractual relationship between the completion of deliverables and the cost of the service (which is the reason that at the Federal level such contracts are illegal bwah-hah-hah).  At, at a certain level of disingenuity, that's true.  But you don't have to set up this work in an unaccountable way, unless of course you are just trying to avoid accountability.

Assume for the moment that both the vendor and customer are interested in a quality product (or service) at a reasonable cost.  Do we really think that the vendors let their people just do whatever until a few weeks before the contract delivery period expires?     Of course not.  There are interim milestones and estimates of the work needed to achieve them; in fact, those had to be developed to come up with the proposed cost of the work in the first place.  Except for the very smallest increment of delivery, there is no reason at all that we cannot establish intervening milestones and the value associated with achieving those milestones.  That value does not have to be the costs incurred to date; doing so merely converts the work back to cost-based.  And please do not allow the vendor (or a lazy contracting officer) to set up straight-line progress payments; that, too, converts the work to cost-based.  What are you going to do when after the 11th month it finally becomes clear that the deliverable will not arrive on time?  Now instead of 100% of the payment (highly motivational), then vendor only has 9% of the total payment at risk.  Good luck pressuring them into timely delivery at that point.  You should determine the value of the milestones and pay for those deliveries only when they are complete and acceptable - and if they are late or do not perform as required, you don't pay for them at all.  Now you have deliverables that have schedules and a planned value (which, notice, does not have to be a planned cost-to-date).

You can get a simple template that allows you to produce an EVM graph and metrics in this manner (see the Solutions tab).

Tune in next time for a discussion of EVM in a Level-of-Effort situation.

Trust but verify - heavy on the verify

If a decision happens but nobody writes it down, does anybody hear it?
If a decision is published but nobody checks to see that it is being followed, will anybody follow it?

Why can't you see the glass as half-full once in a while?
We've got good people here. We told them what we wanted to do. They don't need to be baby-sat.

If everyone was in agreement we would just go ahead and do it.
The reason we have highly-paid executives to decisions is that there are conflicting points of view as to the best course of action.
Therefore, whatever they decide is going to differ from what a good proportion of the next layer or two in the organization would have done if left to themselves.

At the same time, most executives didn't get where they are by having no political instincts, which means that quite often they say things that they don't really believe because that seems like the proper thing to say at the time.
So it's entirely possible that a decision isn't really a decision, more like a pronouncement to kick the real decision down the road a while.
All very Byzantine.

So what do people do while trying to get on with life in their smaller part of the organization?
If the executives don't have the gumption or the stamina to make sure that their decisions are carried out, it sends a pretty strong signal that they don't care too much either.
Then the people who didn't agree with the decision in the first place won't be very deterred from giving it at best lip-service until they find out whether this initiative is anything more than the fad of the month.
The first sign that the decisions aren't really decisions is that the deciders don't really want anyone to know what they decided or why.
It removes their latitude later for changing their minds.
Of course, in the short run, it also means that it is more likely that the decision will be ignored.

If our governance decision authorities (whether boards or individuals) are serious about having their decisions respected and followed, then:

Write down what was decided in clear terms: Who will do what by when with what resources

Include enough information to understand why the decision was reached and any issues that were raised<\li>

Publish the decisions to those who are affected - at all levels. That way intermediate managers can't slow-roll or pocket-veto.

Follow up on the progress of the actions that were decided on

When it makes sense to do so, change a decision and publish the fact that it has been changed

Assuming that the PMs and/or staff have done due diligence before offering up solutions for the board to approve, then the approved course of action should be achievable.
If the intermediate managers can't or won't get things done, find someone who will.
Preferably someone who was rooting for the original decision. It will greatly improve the quality of analysis in the future.

SAFe - acronym or solution?

The Agile approach to project delivery has gone mainstream over the past few years.  Now the big question is whether Agile, with its focus on self-directing small teams, really can be used effectively in to produce solutions that are necessarily very large-scale and highly complex, with serious consequences for getting it wrong.  "People might get killed" would be a serious consequence.

Such work is often found in the public sector, and you can tell that a concept has already been mainstream for a while when the government starts pushing it as the latest thing.  As usual, the latest thing is also being pushed as the silver bullet that will make government programs super-efficient.  The truth is that government projects don't fail because of process - they'll get enough money thrown at them to overcome a whole lot of process inefficiency.  They fail because they are - well, complex and very large scale to the point that nobody really understands the whole solution to the point of being able to assess the consequences of a butterfly wing flapping on one side of the effort.

Most of the heavy-duty engineering processes are intended to mitigate the risks posed by those conditions by at least trying to document what is going on and making sure that everyone involved has a chance to put in their two cents as to potential impacts when an change is contemplated. But it takes time (and money) to write all this down, time to read and understand it, and time to comprehend the implications of proposed changes to it.

Discussions of "Agile at Scale" have been going on for several years, but one leading candidate approach to achieving that goal is the SAFe method (http://www.scaledagileframework.com/).  I have not studied it enough yet to say that it provides all the meat that is really needed (for instance, a comparison with DSMD would be useful), but it has some solid case studies and it is certainly attracting the right sort of attention. A lot of that may be due to the brilliant acronym for dealing with government offices because it addresses precisely the number one concern: can a system developed via an Agile process be considered "safe"?  "Safe" having many meanings:

• Will it grow to support tens of thousands or millions of transactions or users?
• Can we trust it in life-or-death situations (military, air traffic, fire or police dispatching, etc.)?
• Will it be proof against determined cyber-attack?
• Will we be able to use it and repair it many years from now when the current leading-edge technology is long obsolete?

And of course the most important question: "Will this go well enough to delivery that I won't be embarrassed by having championed doing something different?"

There is no way that a development project can deliver quickly if every aspect of the surrounding infrastructure (both physical and process) has to be debated at length is not re-invented from scratch for each project.  My own interest in the topic was stirred through being unable in several different agencies to get any pragmatic or pro-active guidance from enterprise architecture or from IT security; even waterfall projects would complete half their development work in the time it would take to get a review of the initial concept.

That simply won't work for an Agile approach. The enterprise needs to make key decisions at a high enough level that they can be defined and decided (even if they have to be changed later) so that the development teams can get on with providing those useful deliveries. And the enterprise needs to be protected from short-cuts taken by fast-moving but tunnel-visioned project teams.

My favorite quote in the SAFe materials is the idea that Enterprise Architecture must be treated as a first-class citizen.  To that I would add, "and enterprise architecture needs to earn its citizenship", by providing the patterns and guidance that project teams need - or agreeing to work with the front-running project to tweak its requirements to permit the adoption of whatever the team comes up with as the enterprise standard.

I don't know that SAFe really does address all the legitimate concerns of an enterprise, or whether it really only does so using the same processes that would also be employed by any competent organization even if it were using the waterfall life-cycle model.

Anti-maturity; When It Just Isn't Worth the Investment

How often, really, have organizations started down the roads of project management, governance, enterprise architecture, internal controls .. you name it, they've tried it; but after the dust settles, the initiative has failed and faded like so many before it.  And now, you, lucky you, have been named to lead the next new fad.

Let's face it, a lot of organizations manage in spite of themselves to ride market forces to a place where corporate resources can absorb a lot of mistakes.  For optical purposes they may have to satisfy oversight groups, regulators, shareholders etc. by trying out some new approach, but they don't see any terminal consequences of paying nothing more than lip-service to the idea.  You, however, will join the long list of casualties.

Is there a way to tell whether an organization simply isn't interested in the types of benefits that these initiatives might create?  Kudos to Kik Piney for developing the Anti-Maturity Model.  You can read his approach (which he says isn't fully developed but you will find it pretty informative just the same). The gist of it is that you are wasting time trying to climb off Level 1 of any maturity model if the overall organizational culture is going to actively undermine most of the key elements of any process or discipline.  Immaturity suggests that you want to get better but don't quite know how; anti-maturity means you don't really want to improve.

This model might be also be helpful for many PMs in career considerations.  As you work your way up the PM ladder, the sign that you have actually arrived is that great interview where the panel emphasizes how the organization has come to really value the benefits that some aspect of PPFM can bring, and how they need someone with your experience to really bring it to life.  On the strength of an hour or two, how will you find out whether this is really the job you've been working towards for years, or the beginning of a 2 or 3 year nightmare featuring broken promises, carer threats, and endless wrangling?  You'll live through it, and be the stronger for it in the end, but how much nicer it would be for all concerned if you could determine in advance of taking the gig. Maybe a working knowledge of the symptoms of anti-maturity would help ask some penetrating questions during this same interview.

Kik doesn't get into why an organization would choose to behave that way.  It's often useful to observe the behavior and respond based on a knowledge of how an actor will behave, rather than speculating (often incorrectly) about why.  Having said that, recall that people rise to the top of an organization because their particular skills and preferences fir the way that organization works; once they rise to the top, they pass those same predispositions onward. For instance, IT organizations should in theory be run by managers with experience running IT operations; but all too often IT operations are run by people with a history of seeking to be responsive to customers  and other stakeholders by making undocumented on-the-fly changes that bring the whole system down -- and then build their "team player" credits by coming in overnight to fix the problem that they would never admit to having created.  Then, of course, they are promoted because they always got the extra mile.  Then they read a book about how great ITIL is, or maybe an external audit forces it on them. Do you really think there is any chance of success? Do you think it is a coincidence that something as inherently obvious as the precepts of ITIL has had rather limited adoption? The whole scenario is anti-maturity at work.

Enjoy the read!  

Minute-o-phobia

In a separate post we discussed several different views on the appropriate level of accuracy to include in meeting minutes.  I also noted that even more prevalent than different ways of taking minutes is for a meeting to have no record at all.

We all know that spies and politicians do this, but surely the entire PMBoK is about transparency, consistency and making a record. Yet so many PMs are among those who seldom document a meeting (at least for public consumption; what goes into your little black book for self-protection does not count!)

Why so little practice of transparency?

• Some PMs perhaps think that taking minutes (and more importantly, typing them up) is a secretarial function and they're much too important for that. Bad thinking. If you put the meeting record together you can make sure that the important things are included and that the needed actions are assigned. I certainly wouldn't want to say that you can remember the meeting sort of the way you want to ... but it happens that way sometimes ... don't overdo it.
• I know I often forget, or maybe a day or two of back-to-back meetings overcome your good resolutions, and the next thing you know you are twelve meetings behind and what the heck, nobody will notice missing a week. Which may well be true. And the next thing you know it's a month.
• The committee holding the meeting doesn't bother to read the minutes, offers no corrections or clarifications, and never votes to approve them. Why bother? {Ahem. See the first bullet).
• The committee members don't want to be held accountable for their decisions.  Now we're getting somewhere. Is it that they really don't want anyone to know what they decided? Ask them how anyone is supposed to do what they decided if nobody knows what that is. If you're still not getting any sensible answers after going down this road, consider whether your organization is so process-phobic that trying to implement PPFM is pretty much a waste of time (see the Anti-Maturity posting)
• Actually it's more likely that the members are OK with having votes etc recorded but they don't want a record of who said what in the deliberations leading up to the vote. Well, all right. If that's the only compromise you have to make in implementing your governance process, you are well on your way.

Here's another old favorite: our team is small and everyone knows what's going on. Why waste time on administrative overhead?
Hmm. Ever heard of turnover? Ironically, the logic is almost the reverse: the tighter your group, the harder it is for a new person to come up to operating efficiency. It's amazing how many processes that "everyone knows" turn out to be known in a different way, or not at all, by almost every member of the team. When a new person comes on board, it is of enormous help to be able to take a few hours reading through an abbreviated life history of how we got to where we are. Of course the minutes won't tell you everything you need to know (nor, unfortunately will your new team-mates) but within a few hours hours the newbie is at least familiarized with the issues and the stakeholders.

I'm not insisting that senior managers be the actual scribes or document typists. Go ahead and have someone else do it. As long as it gets done.

Which PPFM Skills to Implement First: The Spaghetti Axiom

People get all wrapped around the axle about how to implement PPFM.  Most of the methodologies have very structured prescriptions for doing this, not only at different "levels of maturity" but also detailed steps within a level.

For the most part, reality doesn't work that way.

Implementing PPFM in an organization for the first time (or worse, for the nth time) requires culture change, and it is quite a substantial one.  That's true even if the organization has at least the required degree of maturity to begin contemplating such an effort in the first place.  See Kik Piney's not-so-comedic article on the Anti-Maturity Model.

Think of PPFM as a nice steaming bowl of yummy spaghetti with equally yummy sauce that will, if mishandled, make some spectacularly messy and probably permanent stains on your best business suit. Obviously it must be handled with care.

Given enough time yo could probably come up with an optimal way to eat this delicious mess.  The third strand from the middle is the one hanging everything up, if you can just get to that one ... your lunch companions are not going to wait for this sort of nonsense.  So you stick your fork in there, twiddle it, and get what you can.  It may not be ideal, but it works well enough to keep everyone satisfied and the bowl gets eaten in a reasonably timely and tidy manner.

PPFM is like that.  Because of the interconnectedness of the iron triangle, any positive traction on managing scope, schedule or cost is going to have an immediate effect on the other two legs, and likely will impact the other PM areas also.

Are we having difficulty getting people to define the scope of their projects?  Move on, move on!  Get them to agree to making a list of the projects and committing to some due dates.  As the due dates get loser, the project teams will suddenly develop intense interest in the meaning of "done", and in order to avoid such misunderstandings in future the PMO will be required to write down that X is all that was agreed to.

"Stupid PMO, why didn't they think of that before?  Making us look bad."  Stupid like a fox.  Now the PMO is "forced" to implement proactive status reporting, scope management, schedule management, and quality management.   All the things people said there was no way they were going to do that.  Keep applying the Spaghetti Axiom - don't try to force people to eat the whole bowl, just pick a few things that will be productive and accepted, and will have a lot of knock-on effects. Sooner or later, and much sooner than anyone would have thought possible, you'll be at maturity level 2 or 3.

The Spaghetti Axiom: eat it or wear it.

Program management cannot mean just anything

Program management is a term used so much that it has taken on a wide range of meanings, which is to say that effectively it doesn't really mean anything. Oh dear.

Definitions are pretty boring and tend to invite the word-lawyers into the picture, but sometimes you just have to decide what the heck you are talking about. Otherwise your efforts to make improvements fall prey to arguments about who is right when in fact you are talking about totally different things.

So, what do I mean by program management?

Let's not agitate too much over the "management" part. The important part is that it means that the undertaking is too much for one person to overcome by brute force, or even by brilliance. Managers set the stage so that the elements within their system (and, principally, the people who are working on those elements) can succeed.

What about the "program" part?

PMI has expanded its definition over the years. The Project Management Body of Knowledge (PMBOK)(R) used to insist that a program was a collection of related projects, but could only be composed of projects, that is, no operational activities. That flew so obviously in the face of the experience of so many PM professionals that over the years the definition was expanded to include "some" operational component and eventually PMI published a Practice Standard for Program Management in which the operational-to-project mix was no longer relevant.

PMI's current (Dec 2014) definition is "A group of related projects, sub-programs and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually".

Well, yes. And of course "program management" is the "application of knowledge, skills, tools and techniques to a program to meet the program requirements and to obtain benefits not available from managing them individually". Well, it isn't wrong, but it does seem trite. It would be pretty hard for the average person to tell whether they are a program manger or not, given that definition. And so the debates begin.

And, before that starts, let's be clear that a program is not a portfolio, at least not in my musings - there's a separate post on portfolios. A portfolio is used for broad-based analysis, but it is not (usually) an actual decision process. Portfolio managers make recommendations (some may even have a veto), but it is the program managers who get to make decisions.

In the US Government the idea of programs has been around for along time, as have processes for managing them. The Defense Department's program management practices amount in essence to project management for very large projects. Although they are very complex, they do not begin until the "program" has been approved for funding and they end when the product reaches Full Operational Capability and can be handed off to the military services to conduct operations and support. (Yes, true, there are follow-on modifications and versions over a product life-cycle, and at that point one moves towards managing a program instead of a really large project, although I would contend that not having responsibility for support relieves the manager of such a product from one of the key responsibilities of a program manager, which is to balance the resources needed to sustain operations with those needed for innovation).

If you're part of the Washington sub-culture then you also know from the Programming, Planning, Budgeting and Execution System (PPBES) process that there are major programs and appropriated programs. On the other hand, companies talk about the Human Relations program. Schools talk about their sports programs. And the third grade music recital has a program. Are these all really the same thing?

Our musician son puts together musical events. A typical event consists of a variety of different contributions, with the genre and performers selected to balance different goals. The acts are not really dependent on one another, except to the extent that one must follow another in some sort of sequence. Why is this not a portfolio? First, because that industry doesn't think in those terms. But in any case, all of the acts do depend on the program manager to furnish some common infrastructure and some definitive guidance. He gets to decide who is in and who is not (while in some cases having to persuade people to get in). He provides the venue and makes sure that the logistics are adequate. He arranges for someone to collect the money, which is later shared along some formula that he has orchestrated among them.

Now one such event on its own is really a project, perhaps with several sub-projects needed to get all the pieces to fall into place. But there is also an ongoing capability beyond the execution of the immediate event: it will be back next year, hopefully. So there is are ongoing activities, such as fund-raising, venue planning, and a general (if limited) management and governance process. It's a program! So is a football program: it goes on well beyond one event or even one season, and it definitely goes on longer than the career expectancy of anyone involved with it.

The program creates the environment in which a capability is sustained: the environment and the necessary processes must be there before the projects have a beginning, and they are there after the projects come to an end. Sounds somewhat like the Book of Genesis. Well, in a way it is like that. Whether it is a massive appropriation of funds to a government agency, or dad or mom's paycheck that enable junior to acquire a means of transportation, there is a finite limit to the resources and there must be a means of balancing them between competing priorities. The program managers focuses less on the week-to-week outputs of the projects or the operational activities than on the long-term building and sustainment of a capability to do work. In doing so, the program manager focuses on what DOD likes to call "Big A" acquisition (little A meaning just contracting actions). "Big A" does include contracting, but also skill sets such as planning, budgeting, financial management, human resources management, facility planning etc.: all the skill sets required to make sure that resources are in place when the work needs to be done.

Seems pretty obvious. Yet it is surprising how few organizations actually do this. Enormous expenditures are made to implement project management, but over years and years not much difference is seen. Why? Because the environment has not been conditioned by program management to make project management successful. No matter how hard they try, project managers cannot seem to bring projects in on time, on budget, with the desired capabilities, because the leadership, planning, guidance and coordination are not in place. Projects are under-resourced to the point that they cannot accomplish their aims, or, just as bad, over-resourced to the point that they are bloated, lose sight of their original aim, and crowd out all the other work that could have been done. Deliveries from one project to another are defined only by trial and error. Staffing begins only after the project is underway, guided by the untrained personnel who were the only ones on hand at the time: go, go, go! Nobody really knows who is working on what, except that everyone is sure that nobody is working on the Top Ten list. If any of this sounds familiar - you need to focus on program management before your project managers can be successful.

One hardly ever hears of an organization saying "gee, what we need here is to institute program management". Much more common is to hear that it has symptoms of issues in multiple areas at the same time. It is quite impossible to to fix project management and financial accountability and resource prioritization and effective planning and, and, and, all at the same time. In such a situation - and they are more common than you might think - the organization needs to get its act together from the top down and start managing holistically. That will mean making progress in small enough increments that they can be digested, even though each step will not move the needle much on anybody's Maturity Model. Of course, our objective is not to get a good score on someone's model, it is to make a positive difference in our organization. Besides, real life is not quite like the regular-looking steps on most maturity models: it's more like a critical mass thing (The Spaghetti Axiom).

So what do I mean by program management?

Program management is a method of applying a multidisciplinary approach to establish, maintain, and improve a complex capability over an extensive period of time, by establishing the environment in which the program activities can be successful, by defining and approving solution components, and by coordinating smooth transitions between existing and emerging solutions repeatedly through the life of the program.

Please feel free to enrich this understanding with your comments!