Microsoft Solutions Framework

July 1, 2008 at 1:58 am | Posted in Development Management, Project Management, SDLC | 2 Comments

When it comes to managing I.T. projects it makes sense to learn from a company that has been doing it for 3 decades.

Microsoft have had the opportunity to develop software solutions on a scale that cannot be touched by even its closest competitors. And over the years they have refined and harnessed this experience into a solutions framework and made it available to the rest us.

What is the MSF?

Microsoft® Solutions Framework (MSF) is a deliberate and disciplined approach to
technology projects based on a defined set of principles, models, disciplines, concepts,guidelines, and proven practices from Microsoft.

and …

Microsoft Solutions Framework … [is] a loose collection of best practices from Microsoft’s product development efforts and Microsoft Consulting Services engagements …MSF has been evolving … based on deliberate learning from the
successful, real-world best practices of Microsoft product groups, Microsoft Services, Microsoft’s internal Operations and Technology Group (OTG), Microsoft partners, and customers. Elements of MSF are based on well-known industry best practices and incorporate Microsoft’s more than 25 years of experience in the high-tech industry.

Microsoft Solutions Framework version 3.0 Overview whitepaper   

My take on it is that it is basically your typical SDLC dicipline with extended “soft” features added – let me explain.

 Let’s take your typical SDLC:

Nothing new here right?
Well MS have taken this design and added some essential extras such as:
Open Communication
Learn from every experience
Manage Risk
Expect change
Shared Vision
Empower Team members
And a biggie …
Establish clear accountability and shared responsibility.

As well as adding some intermediate steps eg:
         MSF: Envision
       MSF: Stabilise

Another useful tool that the MSF employs( and something I haven’t seen many other companies focus much on ) is end user experience.
“Yes Yes,” I hear you say, “we have been doing this all along, nothing new here.”
Well maye. But the fact that they have formalised it and made sure that it is another check box that gets ticked makes it really useful in my opinion.

The MSF also includes a list of roles and assigns duties to them. I found this to be a very interesting aspect. In my experience roles have been pretty well defined. There is the ‘BA’, the ‘architect’ the ‘tester’ etc … but the MSF goes beyond this in that it assigns ‘groups of roles’ to ‘project goals’ – a very interesting concept that I need to spend some more time looking into.

Of course, the MSF is a whole lot more than this but it would be impossible in a one page blog to fully capture everything that is the MSF.
My purpose here is just to let you know that it is out there and that it is a great tool for managing I.T. projects. In fact I think that the MSF is the perfect marriage between Development Management and Project Management.
Why do I say this? Well for me the SLDC seems to focus soley on the ‘process’ with very little regard for the ‘team’. The MSF tries to include ALL the elements that go into successful project delivery.

The reason it is called a framework is basically because it is made up of various components that can be used individually or together to achieve the desired outcome. The MSF offers a ‘wholistic’ approach to solution delivery. A very high level breakdown would be as follows: (Taken from their whitepaper)

• MSF foundational principles.
     The core principles upon which the framework is based.
     They express values and standards that are common to all elements of the framework.
• MSF models.
     Schematic descriptions or “mental maps” of the organization of project teams
     and processes (Team Model and Process Model—two of the major defining components of
     the framework).
• MSF disciplines.
     Areas of practice using a specific set of methods, terms, and approaches
     (Project Management, Risk Management, and Readiness Management—the other major
     defining components of the framework).
• MSF key concepts.
     Ideas that support MSF principles and disciplines and are displayed
     through specific proven practices.
• MSF proven practices.
     Practices that have been proven effective in technology projects
     under a variety of real-world conditions.
• MSF recommendations.
     Optional but suggested practices and guidelines in the application
     of the models and discipline 

If you are a serious development manager I would highly recommend that you spend some time investigating the MSF. It is an invaluable tool to add to your management arsenal.

For more information please visit their site at:



How to cost a project

April 28, 2008 at 2:53 am | Posted in Project Management, SDLC | 1 Comment
Tags: , ,

If you have been asked to estimate the cost of a project, the best way to arrive at a reasonable figure is to breakdown the project into its SDLC components.
SDLC milestones may vary but a general breakdown is as follows:
1) Analyse
2) Design
3) Develop
4) Test
5) Deploy
6) Maintain

Like I said, these are just a high level breakdown but they are a good place to start.
Let’s examine each phase in depth.

This step usually involves the Business Analysts. Each BA has their own way of doing what they do, but it sometimes involves USE CASES and other analytical techniques to achieve a reasonable understanding of the client’s requirements.
This task usually involves a software architect, who liaises with the BA team to gain an understanding of the solution requirements.
This phase is usually led by a Lead Developer who takes the architect’s plans and converts them into a product.
Depending on the type of organisation you are dealing with, this will either be a specialised person / department or it may involve one or more developers from the development team.
This part of the project involves the OPS or IT departments as it normally requires infrastructure assests such as servers etc.
On going bug reportng etc ….

(Please note that very seldom, and in fact never in my experience, does the SDLC actually flow from top to bottom in a linear fashion. There are usually several loops between development and testing etc This topic is on costing and not the SDLC)

When costing a project one needs to start with the following procedure:

  • Hold a ‘Vision and Scope’ meeting with representatives from each of the SDLC teams. In this meeting a high level understanding will be reached as to the expected outcomes of the project.
    Each member will go back to their teams with an outline of the expectations, and be required to gather estimates as far as resources, timelines etc
  • When the project team next meet, all figures are made public and the team members substantiate their estimates under the scrutiny of the other team members.
  • Once a concensus has been reached the Project Manager will draw up a cost estimation based on the outcome of these meetings.

Obviously costing is only one aspect of the PM cycle, and this particular example is based on the ‘Delphi Wideband Method’.

Create a free website or blog at
Entries and comments feeds.