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.
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.
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:
Learn from every experience
Empower Team members
And a biggie …
Establish clear accountability and shared responsibility.
As well as adding some intermediate steps eg:
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
• 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:
Many developers seem to think that they are limited in their career options once they finally reach the point when they no longer wish to be directly involved in the coding process. I too reached this point in my career, and after some soul searching I basically decided that there were 4 paths that I could follow:
This is usually the logical choice for those who still wish to maintain some technical involvement but move into a higher visibility level on the corporate ladder. The majority of architects arrived in their current position by slogging it out as a senior developer or technical lead for some development house ( that’s me 🙂 ) and as such have a really good understanding of the coalface technicalities of designing a solution.
Again, senior developers usually have a decent understanding of the SDLC and as such would have some valuable insight into costing and effort estimates. However one needs a lot more exposure to resource juggling and considerations of resources outside of the development team.
In my experience developers can be quite insulated from clients, BA’s and even the entire testing process. A PM will be involved with all these stakeholders and it is a really good idea for any developer wanting to step out to gain as much exposure as possible to these facets.
Heading up a team or teams of developers at various client sites is another option that a ‘retired’ coder could follow.
The obvious skill that needs developing in this area is ‘contract negotiation’. As a developer you will likely never have been exposed to this aspect of the project. There are areas of the SDLC where a PM and DM’s roles may overlap but I see the DM as more a solid line reporting path and the PM as a dotted line. A DM will need to be more involved in H.R. issues and not many people enjoy this aspect of the job description.
Complete Career Shift
This is pretty self explanatory, but if you want to use your technical expertise then perhaps you could be a technical writer for a local magazine or website – or you could write a book.
You could become a teacher / trainer of IT or even assist with technical documentation.
I would advise spending some time doing due dilligence to each of the choices by researching the domain knowledge within each discipline.
Spend some time researching the various architecture frameworks eg: Zachman, try and think of where you would use each one and spend some time trying to apply each framework to projects you may have been involved in.
Find out what the pro’s and con’s of each framework are and read as many case studies as you can on each one.
Research the various methodologies eg: PRINCE2 and try and apply them to projects that you have been involved in. Also, do some practice project costings to see how you would have done in estimating the budget for a particular project
Get involved in ‘first contact’ scenarios when a project is proposed and a client is introduced.
Get some exposre to business law, contract etc and learn from those who have held the position in the past.
I am sure that there are many other options out but these are a few that came to mind as I pondered my own fate.