Microsoft Solutions Framework

"The difference between a boss and a leader: a boss says, 'Go!' -a leader says, 'Let's go!'”

                                                                                                - E. M. Kelly

Sometime in a previous (professional) life, I worked for a company that used Microsoft Solutions Framework.  This was a very long time ago and I don’t even remember the company.  As a development framework, MSF didn’t really impress me much at the time, but there was one key element of MSF that did impress me and has stayed with me all of these years.

It may be that I wasn’t that impressed with MSF because the company that was using it wasn’t the best candidate for it.  MSF is ideally suited for software development for distribution (i.e., to consumers).  My client (employer?) was using it to develop software for internal use.  Further, they weren’t set up with the appropriate infrastructure and architecture for daily builds.  It was good they were using a development framework, but other choices would most likely have been more appropriate to their organization.

(This paragraph is an attempt at sarcastic humor.)  I have never used MSF in, what I would consider, an appropriate context for MSF.  However, Microsoft has years of success using it to deliver reliable, user friendly, quality software on schedule.  Therefore, I will accept their experience as its endorsement.

Nonetheless, I got training on MSF at my client.  As a framework and not a methodology, MSF is (intentionally and appropriately) light on the “how” of software development.  One area of the framework, however, is fleshed out in particularly specific detail:  the MSF Team Model.  The MSF Team Model has several favorable attributes:  it is specific about the roles (and responsibilities of those roles) that must be represented on the project team;  it is specific about the relationship of the team members to each other;   and it intentionally creates conflict between roles to establish natural “checks and balances.”

Prior to my training on MSF, my experience with building project teams was to have the “right” people.  But that is unabashedly vague.  Further, we may know that the team members we have are the right people, but how do we know what right people we might be missing?  The MSF Team Model resolved this weakness in my experience and practice.  Further, I know of no other framework or methodology that puts such emphasis on composing the team.

Therefore, as a Best Practice, I want to pass on the benefits of the MSF Team Model and strongly recommend that you consider the MSF Team Model on your projects.  More information on MSF and the Team Model is available in Microsoft Solutions Framework Essentials by Michael S. V. Turner (Microsoft Press, 2006).  Chapter 4 discusses building an MSF Team.

Have you had experience with MSF?  What is your opinion of the Team Model?

© 2013 Chuck Morton.  All Rights Reserved.

The Schedule – Resource Leveling

“Happy people plan actions, they don’t plan results.”

                                                                                                                - Dennis Wholey

We are nearing the end of the series on scheduling basics.  We have taken the WBS, added the dependency chain, estimated the effort and assigned resources.  The next step to completing the well-formed schedule is to level the resource assignments.  This is done to:

• Prevent over allocation of a resource within the project
• Prevent over allocation of a resource across enterprise assignments
• Accommodate non-productive time and absences

First, let’s assume the project is in an organization following best practices.  In that case, all team members record all of their time each cycle to specific project tasks and to operations, administrative, absence, and other non-project activities.  Your project management software integrates with these time records (or time is entered directly into the software, such as Sharepoint wih MS Project EPM, Clarity or Primavera).  In this case, you already have all of the elements in place to just “push the button” on your project management software to resource level the schedule.  You will then want to review and fine tune the results.

On the other hand, if you do not have the luxury of these conditions, you have more work.  For example, you will have to tune and adjust using heuristics to get the right productivity factor so that you don’t over allocate resources within the project;  and it will be much harder to track other assignments and activities to prevent over-allocation across enterprise activities.

In either case, this step will be repeated regularly over the life of the project.  Rescheduling and replanning are regular activities in the Project Manager’s Cycle.

In my next post, we’ll conclude this series of posts on the basics of creating the well-formed schedule by discussing risk buffers.

If you are not in a “best practice” environment, what steps do you follow to produce a resource-leveled schedule?

The Project Manager’s Cycle – Negotiate with Resource Managers

“Rainey, are you aware of any recent changes with Mani?” Don was having lunch with Rainey, the Analysis and Design Manager and Mani’s resource manager.  “She’s missed a couple of deadlines, which is unusual for her, and one of the business contacts mentioned she’s been ‘testy’ in some of the meetings.  I’m concerned.”  Rainey, after a thoughtful pause, replied “Have you asked her about it?”  “No,” Don answered, “not yet.  I will talk to her this afternoon; since we were here, I just thought I’d see if you had any background.”

Up to now in my series on The Project Manager’s Cycle we’ve primarily been working with numbers and reports, with little communication outside the project team.  This is the first activity where we start coordinating with project stakeholders.  This activity assumes a matrix organization, where you have temporarily and/or partially borrowed resources from department managers in order to staff the project.  If you own the resources – that is, they report directly to you as their line manager – then you can skip this activity.

This activity takes as input the results of the previous two activities:  replanning the schedule and reviewing team member progress and productivity.  As a result of those activities, there may be changes to the planned utilization of team members or concerns about their performance or productivity that you need to discuss with their managers.

For each project team member, prepare a schedule that shows their expected allocation by week for the next several weeks.  Depending on the organization and the resource manager’s planning cycle, this may be as short as 3-4 weeks;  other managers may require three months or a full schedule showing the allocation as long as the resource is needed.

You may also want to provide the information by task with completion dates, depending on the detail that the resource manager wants to see.  You can use your scheduling tool’s Gantt chart feature or populate a spreadsheet.

Provide these reports to the resource managers and, where appropriate, schedule to meet with them, especially if there are performance or productivity concerns.  Review the report, productivity, progress, and any changes you’ve noted from prior weeks.

But don’t expect the resource managers to just accept your plan.  They may actually have assignments, priorities, and expectations for these same resources, which, of course, may require some negotiation on your part and the possibility that you are back to replanning the schedule.

When you have performance or productivity problems with a project team member, do you talk to the team member first or to their resource manager?  Why?

The Project Manager’s Cycle – Reschedule/Replan

“What do you mean ‘You’re going to be gone for four weeks starting next month?,’” asked Alice, after picking up the phone on one of the rare occasions she was actually at her desk and listening to Ravi explain his new vacation plans.  “But … well, you didn’t know.  I just found out that Infrastructure is slipping their schedule so we’re going to need you until the end of the month after all.”

Now we transition from initiation activities to planning and design within The Project Manager’s Cycle. 

If it hasn’t been done already, all the team member updates from the metric validation and the task validation need to be posted to the project schedule, including closing completed tasks, updating effort estimates, and opening tasks ready to start.  Your perfect plan from last week is now corrupted from just one week of actual results – new end dates, team members who are now over allocated,  team members who won’t be available as previously planned due to conflicts or newly planned absences, newly exposed issues, political maneuvering, prioritization conflicts, team member conflicts, and stakeholder conflicts.

Now you, the project manager, apply intelligence to scheduling, adjusting start dates, shuffling tasks, balancing resource allocations, and drawing on schedule buffers as needed.  Sure, your scheduling tool “auto schedules” and probably has an option to load-balance resources.  However, the rule engines for these are notorious for making obscene messes of your schedule.  Depending on the need to maintain the original target dates and prevent slippage, you may need to consider adding resources, overloading resources (OT), reducing scope, and crashing the schedule.

As a further part of this activity, you will also address event-driven activities, such as unplanned/dynamic impacts, deliverable acceptances, reprioritization, issues, problems, commitments, and the other conflicts mentioned above.  This may involve adding project tasks, reassessing resource assignments and allocations, changing task estimates and getting team members to re-estimate their task assignments.

The end result is a new draft schedule that you have to validate and “socialize,” which transitions us to the next activity in The Project Manager’s Cycle and sets the stage for my next post.

Unlike most of the other activities in The Project Manager’s Cycle, rescheduling and replanning is not something that is done and then completes.  Rather, every thing you as the PM does has the potential to expose a need to adjust the schedule;  adjusting the schedule has the potential to expose the need to further adjust the schedule or to take some action that will … well, it’s called The Project Manager’s Cycle for a reason.  This keeps happening ever and forever for the life of the project.    You are constantly restarting this activity.  Plan on it.

How do you live with yourself when you have the perfect project plan?

The Project Manager’s Cycle – Validate the Metrics

“Okay, I’ve posted my hours now.”  “Great, thanks.  Let me check the reports…  It shows that you have four more hours to complete the task and that you’ll be done on Tuesday.  Is that correct?”

a)      “No, sorry.  It’s complete, I just forgot to update that part.”

b)      “Yes, that’s right.”

c)       “No, the mapping is more complicated than I thought.  It’ll be Friday, at least, before I’m done.”

The Project Manager’s Cycle involves taking in raw or rough data, processing, validating and acting on the data, then organizing the result into a coherent model for communicating to your stakeholders.  The initial data comes from reports by the project team members.  They report the state of their tasks relative to the plan, including progress/completion measurements for each of their assigned tasks.

The ideal source of the initial metrics is an enterprise project management tool, such as MS Project Professional with EPM, CA Clarity, or Planisware OPX2, where each team member updates the hours they worked on each task and the remaining hours to complete the task.  Without such a tool, the metrics may be percent completion values and changes to task end dates.  These are not as reliable, but they may be the best you have available.

Something that I have observed is that project team members, even veterans, have to be periodically reminded to make these updates and the expectations for reliability.  For example, the estimate to complete (ETC) must be re-estimated each week, not just reduced by hours worked, for it to be meaningful.  Alternately, percent complete values also need to be re-evaluated, not just incremented.

The project manager receives these metrics and is initially concerned with determining that they are within the expected norms.  That is, that the team member worked the planned number of hours for that week and that the remaining work is as planned.  Note that if the PM only focuses on hours worked (or percent complete), a major early warning indicator is lost.  Hours worked and hours remaining (percent complete and completion date) are a check-and-balance that the team member is progressing according to plan.

The first important validation is that team members are posting their hours accurately.  That is, that all hours worked on this project are posted to the appropriate tasks and only hours worked on this project are posted.  Otherwise, team members may under-report hours if they are experiencing difficulties or over-report hours to obscure time spent inappropriately on other efforts.

With accurate hours reported, any significant deviation, either positive or negative, needs to be flagged for follow up.  For example, if the resource is not contributing as many hours as planned, the PM should coordinate with the resource manager and the team member to determine why and how to limit impact to the project.  On the other hand, if they are working more hours, does that mean they are getting ahead or that they are having difficulties?

It is also appropriate to determine if team members have identified work that needs to be done that was not identified in the plan.  In other words, they need to report hours worked (or will need to report hours in a future period) and have no task to report those hours to.  Of course, as PM you will need to determine whether this work is new (maybe it’s included in the scope of another task), if it is new, whether it is in the project scope, and whether this needs to be addressed through change control or just not done.

Finally, confirm with team members which tasks are completed so they can be closed in the schedule.

Having an accurate and reliable schedule each week requires having accurate and reliable inputs from each team member.  Have you had success getting these from your project team members?

Resource Management Maturity

Linda, the operations director, was again reviewing reports with her development manager Dennis.  “I don’t understand why we continue to have this rolling bubble of demand in the next two weeks, then it drops off to nothing after a month?”  The report Linda was reviewing was the resource demand report.  “Every time we run this, no matter how much effort we’ve put into planning our resource needs, the report always shows we need 200% or 300% of our capacity for just the next couple of weeks, but then it rapidly drops off.  But when we actually perform the work, we have adequate resources, but then the bubble shifts out in front of us again.  What is going on, Dennis?”

Planning and scheduling for resource demand is always challenging.  Just a few years ago, there were shops operating with excess headcount.  Tales from those days might be mythic lore to today’s project teams.  Some organizations are running well below necessary headcount.  Getting projects completed while keeping up with support and maintenance demands requires constant rejuggling of priorities and resource assignments.  People multitask.  Team members are whipsawed from one must-do yesterday to another gotta-have-it-now today.  They are heroes in their organizations, but this is nonetheless poor management and inefficient use of people (though, having been there, it still sometimes beats the alternative).

Interestingly, we can use these examples as heuristics to suggest the organization’s maturity level.  For example, the organization that is scrambling, doesn’t know who is doing what, and is constantly changing assignments and priorities is clearly a Maturity Level 1 organization.  A Maturity Level 2 shop is managing the portfolio of projects, initiates projects based on priority, has basic metrics (task estimates and resource usage), and generally has people assigned when and where they need to be (projects advance based on real-time availability), but limited predictive capability for planning what projects can be delivered based on resource capacity.

A Maturity Level 3 organization has reliable task effort estimates, team members report progress by updating their hours by task and re-estimate the remaining hours, resource schedules are based on productive effort, all resource hours are tracked (project, support, maintenance, admin, vacation, training, etc.), availability is projected based on historical trends, statistical allocations, and planned absences, so that theoretically management can predict which projects can be staffed.  The reality, though, is the situation Linda and Dennis find themselves in.  All the numbers are there, but there is still a fog of misinformation that separates ideality from reality.

Future posts will describe Maturity Level 4 and Maturity Level 5 organizations and address why Linda and Dennis are operating in a fog and what they can do to find the sunlight.

In the meantime, which example best describes your organization?  Do you see value in raising your organizational maturity?