UML or not UML?

Everybody heard about Unified Modeling Language, but when there is some specific question like “what empty diamond means in UML?” most of people don’t know the full answer (including myself :) ). This situation is common as in current complicated world the most important thing is not to know the full answer, but to know where to find it.

UML tools

One of the most popular tool to draw UML diagrams is Enterprise Architect from Sparx Systems. Most of people, whom I know agree that using Visio for UML is kind of masochistic entertainment and IBM Rational Rose is expensive plus you need to buy extra packages to use it fully. EA is not probably the most beautiful tool at the world, but it delivers a lot of horse power to your toolbox and it is very handy. Among others Sparx Systems delivers the tutorial and samples allowing you quickly to find out, which exactly diagram you should draw and how to do it. Nevertheless there is plenty of the other tools like free tinyUML. Full list and quick comparison of free and commercial tools for UML you may find in here.

UML in real

Most of organizations have learned already that stiff approach to UML diagrams does not work. There is no point to draw every single thing, generate the skeleton of classes and then keep constant consistency between logical representation in UML and physical in code. This approach generates very high costs and frustration. The open question is only how many times these two layers need to be synchronized. Absolute minimum is to create them up-front and update UML diagrams during final product delivery, so the customer gets the results with the actual documentation. It happens though in far too many projects, that there is none such an endpoint. As soon as the development starts the UML diagrams are forgotten.

UML in practice basing on RUP

If there is no need to draw every single thing, what is the rule of thumb? Rational Unified Process (RUP) gives here couple of good answers. RUP has been created by Rational Software, which created the first serious tool for UML – Rational Rose. This is why, we can risk saying that RUP was created as the project management opaque for UML. Hans Admiraal very nicely describes necessity to prepare:

• Business Use Case Model (package, use case, activity diagrams) – to represent the interaction between organization and outside world. For example it may describe use case ‘Order a product’ from ‘Customer’ (actor) perspective.
• Business Analysis Model (package, class, activity, interaction, state machine diagrams) - to represent how the business case is realized internally.
• Domain model (class diagrams) – to represent a general concept of a system as a black box.

These models should be prepare during RUP Inception phase, which is responsible for preparing the general vision of the project. Except UML drawings, which describes functionalities and constraints, the vision should contain also the information about:

• business justification (budget versus possible benefits) – the Net Present Value (NPV) may be used in here
• general schedule proposal
• first version of risks register

This is package is called High Level Definition (HLD). If it get the acceptance from the decision makers the RUP Lifecycle Architecture Milestone is achieved.

Then, we go with RUP Elaboration phase and technical details of the vision are specified in Low Level Definition (LLD) package. If HLD is business-driven and it is delivered mainly to take business decisions, LLD is technical-driven and it answers on technical questions. How particular functionalities will be developed? What components are we going to have? Which database will used? Etc..

Of course RUP is just the example and most of the other approaches have similar phases, which boxes preparing the business vision and technical vision. For example:
• Prince2 – “Starting up the Project” and “Initiate the Project”
• PMBoK - initiating and planning processes groups
• MSF – Envisioning and Planning phases

UML in practice basing on EA
Except of three models mentioned above EA offers rich set of model patterns:
Of course there is no need to use them all in each project and this is just the library, from which you may pick up right set of things:

• Business Process Model Pattern – is Business Analysis Model mentioned above

• Requirements Model Pattern – it is a very useful model, which helps you organize the required functionalities especially if there is a big set of them. Privately, when I see the specification where each requirement has its own unique number like FUN_02_03, the one immediately score extra points. The interesting point in here is that a new version of PMBoK (Mr. number 4) contains new processes delivered to support requirements management.

• Use Case Model Pattern – is Business Use Case Model mentioned above

• Domain Model Pattern – is a Domain model mentioned above

• Class Model Pattern – can be used during the work on LLD to specify technical details of the solution. That is especially useful to detect relations and generalizations, especially when you plan to deliver the complex framework and not some standard, typical project. Cool thing about EA is that in resources you may find ready to use design patterns from GoF. EA delivers tools to generate class skeletons in various languages, reengineering tools and even tools to create build scripts. If you are going to document every single class in your code you may draw. This may happen especially if you build your solution over some legacy code. My rule of thumb is that the best approach is to create the class model at the beginning and synchronize it with reality shortly after the delivery to the customer (when waiting for his feedback).

• Database Model Pattern – the same as above, applying it to DB.

• Component Model Pattern – that is a very useful approach to look at physical design from higher level than classes and tables. This thing lies somewhere between HLD and LLD and it is prepared the most often during a planning phase.
  

• Deployment Model Pattern – that is an opaque for deployment diagrams necessary to specify how the solution will be delivered on hardware

• Testing Model Pattern – that is model useful for QA teams to prepare test cases and scenarios.

• Maintenance Model Pattern – during on going use of the system, maintenance model helps to keep the track about the changes to the original requirements. The model can be supportive to introduce the solution like the Integrated Change Control. Nevertheless the most important is to have on board the Bug Tracking System or more advanced Issue Tracking Systems – the nice comparison can be found in here.

• Project management Model Pattern – EA contains the support for resource allocation, effort management, risks management and metrics like use case metrics. That is not a thing, which will replace the MS Project, Excel or the intranet tools, but in some cases it may be useful.

• User Interface Model Pattern – one of the most difficult things during analysis is the design of GUI. Very often the things are sketched on paper or flip chart. Usually when you create some system for the customer, they already have their customs. They may have previous version of the application or there are used to some other critical application. Very often it is just enough to follow the base line. If you create brand new system and there is no base line, my rule of thumb is to create the mock-up. The quickest way to do it, is to use IDE, which will be used later for development (MS Visual Studio, Eclipse, NetBeans). Then you present it to the customer for the acceptance and development has also the start point. Alternatively the EA offers the model dedicated for these purposes. It is not too sexy and if you want to model some specific controls you may need some time, but it allows to show nicely the flow of user interactions at least.

UML specific techniques
Even when you have used the UML there is couple of non-obvious tricks, which can be useful in particular situations:

• Class diagrams – there are the following base type of relations between objects, where each of them may be strong (solid line) or light (dashed line):

o Regular relation – linking two objects. It may have linked association class. It is often used for technical purposes in many to many relations. (regular line without arrow)
o Generalization - indicating some abstracts for some of real objects. It is often used because of OOP when abstract class or interfaces are designed. (triangle, empty arrow)
o Aggregation – presenting that an object consists of 0 or many of the other objects. If the child element is deleted when master element is deleted, we speak about strong aggregation (full diamond). If not, then there is a weak aggregation (empty diamond).
o Dependencies – unlike the regular relation, if there is some direction like using or dependency we use the arrowed line. Very often that line contains also some description, which is a stereotype like <> or <>

• Communication diagrams contains three very nice objects which comes from MVC design pattern

o Boundary - the View equivalent
o Control - the Control equivalent
o Entity – the Model equivalent

• Activity diagrams contains a number of specific options like:o object flow between two activities

o parallel processing (fork and join nodes) versus alternative processing (decision and merge)
o exception handling and exception regions
o partitioning (splitting the diagram on horizontal or vertical stripes)

• Composite diagram specifies:

o Provided (“ball on a stick”) and required (“cup on a stick”) interfaces, which nicely represent the communication issues on technical level. In this way you may for example model communication over WebServices.
o Ports which are represented by the named rectangle on a border of component.
o Delegate mechanism which allows to show that particular class is responsible for delivering external service through the interface or port.
o Collaboration, which allow to group set of elements

At last, but not at least… Whatever you do with UML, it is a communication tool and the most important thing is that it brings add-on value. It definitely helps in communication between two, independent organizations – one picture is worth thousand of words. You should not though document for documentation. Usually it is just enough to document the general idea and the most specific things just in case you come back to the solution after long period of absence. or take over is necessary. The new person in a project should be able to catch quickly the big picture and then to get some answers in more complicated processes and modules. This is where UML can be at great help.

On-line maps

Last time somebody mentioned to me that all maps delivered in the internet comes generally from two companies. Generally that is right, but...

There are two companies on each side of Atlantic ocean. On the left hand we have NAVTEQ in Chicago and on the right hand we have TeleAtlas in Netherlands. Without the surprise most of sources stands that TeleAtlas provides better maps for EU and NAVTEQ has better maps for US, but in Poland...

There are two the most important players: eMapa who has the partnership contract with TeleAtlas since 9 April 2008 and IMAGIS, who after unsuccessful cooperation with TeleAtlas (problems with map conversions) turned into the partnership with NAVTEQ since 15 march 2007. On the internet these maps are provided on two, well known portals:

• docelu.pl hosted by WP, which provides eMapa maps
• zumi.pl hosted by Onet, which provides IMAGIS maps

Two? Really two? What about Google Maps? Well...

Google (as American firm) used at the beginning NAVTEQ maps in Google Maps, however their page for cyclist and runners used TeleAtlas maps even in US. Since 2005 year there was ongoing transition process which caused that finally, today even US maps in Google Maps are displayed today with the TeleAtlas fotter at the bottom ;) It seems to be the result of the partnership contract signed between both companies in the middle of this year.

So are online maps delivered from two companies? Which companies? In 2007 TeleAtlas was acquired by TomTom for 4,5 mld $ and NAVTEQ by Nokia for 8,1 mld $. It seems so, that the competition will move from map producers to equipment producers, but... the biggest producer of GPS equipment is Gemini!

Does Google watch the whole game as the spectator? Well... They bet on half-meter resolution images from the GeoEye satellite. The partnership contract signed in August 2008, gives Google the EXCLUSIVE right to publish these pictures online!

What will bring us the new year?

Outsourcing test process

Development market in Poland become more adult during last couple of years and I am happy to see that there appears head hunting for new job titles like Quality Assurance specialists. That is a strong signal that software houses become more responsible for their products and their do understand that you can not leave the client alone with the software testing. The problem is that sometimes, because of different reasons there is no possibility to build such a team in-house. For example executives believe it is too expensive and despite your error cost analysis their refuse to hire quality specialist. The different reason may be that there is just one big project, which has releases once per month or three and there is no sense to hire full-time employee. These situations happen more often in smaller companies, however there are also situations in bigger once where developer or consultants are testing software and not regular quality specialists. The other topic is that there is quite many tools, which may help you during testing and you must be very experienced person to not buy a crap for big sum of money. There is many potential black holes like test automation, where you can waiste plenty of time and money without a significant effect. Where to install this tool? How to establish test environment which is totally separated from development and production systems (e.g. different domain)? Yes... there is plenty of question and things to do and most of developers don't want and should not make their hands dirty in this mud. Besides... lets be honest. Testing is an adventure and there is often that is repetitive, benedictine work. This is why outsouring QA work is quite interesting solution. The question is only how to do it smart, because it is very easy to get pile of wastful papers from the external company, which does not give any add-on values to your development process.

1. Which cash flow model to choose?

There are generally following possibile models:

A. Times and material - where you pay for time, which people from the external company spend on your projects. There may be different hours wage for people who prepare tests and write final tests and people who actually do the tests. That is definitely the best option where you start cooperation with external company as both sides can easily switch the level of cooperation and adjust it to real needs.

B. Fixed price - if you have some bigger project(s) and there is possiblity to define easily the range of cooperation plus you want to transfer some part of responsiblity on external company, you may think about preparing the contract. The problem is that most usually the border between develoment and testing is quite blurred and this type of deal has always the risk of doing 'only what is in contract'. As live brings many surprised you may find yourself easily in unpredicted situation, where you will have to come to A option any way (e.g. testers must explain developers what the problem is about and contract does not predict such option.

2. What is needed to prepare cost estimation?
That is probably the hardest topic, when you start coopeartion. It is smaller problem in option A as both sides realize that the total value is flexible, but it is very hard topic in option B and most probably outsourcing company will add there some reserver/risk budget for unpredictable situations. Anyway... There must appear answers on number of questions...

A. What is the size of work? The best way is a simple presentation of application and discussion which parts of the system will be tested. Then, basing on number of screens/forms or number of functions plus predicting the number of test iterations, external company will have to estimate their engagment.

B. Who maitain and provide externally test environment?

C. Who installs the software in test environment?

D. What type of tests are done? You have wide range of options:

• code review - basing on provided, general or existing rules you provide report about the code purity
• unit tests - writing unit tests for code (usually should be done by development team)
• integration - putting all the modules together (usually should be done by development team and good idea is to link them with building process - smoke test with daily builds is here a good option)
• installation - test of installation package in different environments
• functional - testing all the functions of code (the minimum package is called acceptance tests)
• platform - testin application on different type of machines, OS systems, internet browsers etc.
• performance - checking how the system behaves (eg. what is response time, how much RAM, CPU, disk space is used) during heavy workload (e.g. many users at one time).
• security - checking if the system is secure and nobody from outside or inside can break in, there is also the option of doing the hardening
• destruction - emulating dummy users (eg. monkey test - play on keyboard like the monkey)
• documentation - check if you can use the system without any interaction with software vendor
• legal - verifing if the application follows particular legal regulations

...

E. What is test approach? Generally the tests are done basing on prepared test scenarios (accepted by both sides) plus some number of ad-hoc test. The question is how many of tests are basing on written scenarios and how many on intuition?

F. What is communication model?

INPUT: The best option is if the external company gets the packed product with instructions and they should do all the tests alone. Then they emulate the real users and situation is quite clear.

OUTPUT: By default the external company will provide the summary report and some list of errors. Most important thing is to have full and detail reporduction list in case of any bug. It should contain the number of action from particular, written test scenario if possible plus as many screenshoots as possible.

Roadblocks
It happens quite often, especially an early stage that there happens the road block - the event which stops QA team from testing all application, module or particular, bigger set of functions. It is opened question how both sides deal with this option and there is wide range of option starting from the very formal one where external company closes whole iteration of tests offically as it is to the very informal where developers delivers quickly some patches. Both solutions have though positives and negatives and each case is different.

Bug Tracking System
More adult organization will provide Bug Tracking Systems, which allows to monitor the life cycle of errors. The open question is who maintain the system and what are the rules of coopeartion? Choosing the particular platform is quite easy thing as there is plenty of options - there is number of interesting web-based open source solutions.



Oursourcing testing process is quite challenging task and there is some risk of miscommunication as testers are usually adding the work to developers and developers are writting buggy code ;) If both teams are located in different companies managers must put the real effort in communication improvment and perfecting the process. On the other hand the external company gives a fresh look at the appliaction, bigger independence in testing and kind of the insurance that a final product is usable. Except detecting errors they may also add number of suggestions/change requests, which make the system *turely* more userfriendly and smooth.

Projects scoring system in PMO

Many of Project Management Office (PMO) realize number of projects in parallel and quite often it raises the resources conflict. That is mostly about people, but it includes also hardware, budgets and the others. Companies fix these conflicts (or not) in different way...

Independent project teams

Very good solution is to organize the whole company basing on project or product teams focused fully on realizing dedicated project/product road-map. The organization structure is quite simple and there is no management conflicts like two managers claiming that particular task/person's work is her/his duty. That approach allows also to assign 100% time of particular person to the one and one thing only, what is base assumption for most Agile methodologies. This allows people also to specialize deeply and company may benefit from it in low "introduction cost" when new project starts.

The drawback of this solution is limited possiblity of resources load balancing. You do not have "universal soldiers", which you can use at various projects and you must accept situations, when particular people have "lazy time" in particular project phases - eg. during stabilization phases developers are not allowed to add new functionalities, testers does not have much to do when developers prepare the first prototype, analysts turn on usually at the beginning and at the end of projects etc. These situations causes that number of companies have dedicated managers/leaders positions, which focus on managing resources in parrarel with project managers...

Renting services from specialized teams

In this approach the project manager (PM), when he starts the projects asks internal team leaders (eg. one for analysts, developers and testers) how much time will cost them to do particular job (eg. analysis, development, testing). PM has also free choice, if he wants to use internal or external resources - it put team leaders in competetive position to the market possibilities. PM has usually a choice, if he wants to supervise personally the resources (smaller projects, times&material) or move part of the responsibilities to subteams leaders (bigger projects, fixed price). That follows Prince2 guidelines and its 3 or 4 level organization.

The drawback of this solution is that PMs compete for resources, what raises number of conflicts. How to define, which projects are more important?

On the surface the answer seems to be simple... Where the purse with possible profits is the biggest!!! :D

Unfortunatelly the devil is details! and it starts from tricky simple questions... What is the probability of gaining money? When we will see them? Are the money the most important? Most of companies have quite high, informal political factor eg. we must do the project X, even when we have small profit from him, but we win in this way very important sector of the market... and similar and so on... Do you know it? If you have PMO, I bet you do ;)

Prioritizing projects

I know that is a horrible thing to write, but... I thought about this, during summer weekend when my skin were becoming brown ;) and then I have reminded myself about Kerzner book "Advanced Project Management", which shows number of real stories like the one above. Quite quickly I have found Drawing 7.8 "Scoring model for one project". The simples solutions are the best, so instead of explaining the whole solution I have prepared the simpler version of the matrix... where each 5 key managers taking a part in steering comitee meetings got 5*[number of projects], which they could spend at any projects as they wanted as far as no more than 10 points are spent for one. When scoring, each person must describe the key factor, which has been used to assign points. Of course the director voice is stronger than managers, so there is also wages system, which is always specific for the company as well as group of people doing the excerise. Generally the whole mechanism is quite simple...

In pratice, you need to do it couple of times until the importance are fitting the company specific and they are satisfactory for the whole commitee. The main target of it is to provide the guidelines for the whole company, when more than one person is engaged in setting the real company's strategy. Of course the whole excercise must be redone once per some time, depending on how often the strategy changes and new projects appear or existing are finished.

And one tip at the end... Take the fat book with yourself, when you introduce the system like the one. When I put the Kerzner (3kg of wisdom) on the table, everybody have been more interested in it, than in the prioritizing concept. It allowed me to go smoothly through the acceptance chain of pain :D

Tips and tricks for start-ups

The internet is lastly like a wild west. We move from the east coast and it seems like we are still far away from the Pacific Ocean. Instead of the run for a ground, we reserve the domain names. The cost of establishing your own business in the internet is nowadays very cheap or even free and there is plenty of people with various specialization, who saw the gold in establishing their own web page. If you have the vision how to put particular process on the web and make the money on it, you just need to give it a name, find doers who code it and partner who will host it. This causes that number of enterprises, which did not have a chance in the past, have the chance to exists now. Very good sample of it, are the survey services and web page like http://webankieta.pl/ - one man can do a change.

The reality is not though so colorful and most of start-ups die quickly. If you think about starting your own business and you do not want to finish it as the silent tomb, consider couple of points below...

1. ALWAYS FOCUS ON CLIENTS OR POTENTIAL CLIENTS – do not loose yourself having a fun watching your desings becoming true; that is a business and business is where the money is. Most of start-ups bankrupt before the first invoice appears – if you cash your first client you WON the first and the most important point.

2. Keep your costs low at the beginning – if you fail you will not loose too much and you will have the strength to start up something new. Pump up the money in the working business - if you cash the first invoice, there will be a time to invest money.

3. Check the competition – you always think you have invented something unique, but there is number of smart people over the world, who do amazing things and you must position your idea among them. Very good way to do it, is to discuss with various people and learn to convince them why your idea is better than the others. If you do it couple of times, it means you truely have something.

4. Find the partner – if you can not convince at least one of your friends to the enterprise, it means that you are probably Don Kichot. No... even he had a partner - Sanczo Pansa. Yes... If plan long journey, you should not do it alone.

5. Leave the solution opened and do not spend too much time on details – the only thing which you can be sure of is THE CHANGE

6. Do the nice graphics – if you do it smart the cost of it is low and this is what clients like.

7. Create the prototype as soon as possible so you can quickly show it to the potential clients and ensure what they truly need. There is a big difference between talking about the solution and showing it. That is also about the agile approach and if it is possible the best way to create the product, is to do it iteratively with your client.

8. Reserve quickly nice domain names – it is quite cheap and you never know who may buy it before you, when you start to discuss it with peoples.

9. The best way to promote you idea over the web is to get the partnership with one of big national portals or worldwide vortals. The other option is to buy the positioning service, which will let your dot-com be found, when people search for certain words in Google, but… you will have a time for it later on. You should find your first client personally at the beginning.

10. When you consider the technical realization of the project ask about proposals couple of companies and verify they offer with some of your technical friend or independent consultant. Set up the key criteria like performance or security and ask straightforward how possible doers plan to realize it. Higher the cost of realization is – more formal the process should be.

Start-ups are exiting and challenging, even when that is a high risk mission. Everybody wants to be a cowboy. If only you will put the attention more on your cows and less on a revolver, everything should be fine ;)

Sucessfull scheduling

I have been asked lastly if I know how to schedule successfully. For novice PM the task seems to be easy in Microsoft Project - simple Gantt chart is all what you need. More experienced fellow, who has realized at least one bigger project will just smile as he knows already how tricky the life is.

PMBoK defines 4 main project dimensions - scope, quality, time and budget. Most of stakeholders likes to track mostly the schedule (time) as it is the easiest thing to track. PM must be a solid man to be able to clarify connections between schedule changes and 3 others things (scope, quality and budget) - this is why the best option is to avoid baseline changes.

There are the following key tips, which should be followed in any schedule - some of them may be for you a cliche, but believe me that they are easy to forget:

1. Ensure that you included any formal holidays (may and december is full of them in Poland) or informal holidays (like the integration camp)
2. Ensure that you included teammembers holiday&training plans within project timeframe (like any other days when they are not at work)
3. Estimate time conservatively, but remember about the Parkison's paradox - somehow even the longest predicted time for a task will be used in 100%
4. You MUST to have some buffer if somebody will be sick, if things will go not as planned - higher the project risk is, bigger the buffer should be. 20% is the default value calculated once by Accenture.
5. Include milestones (0 day long tasks) to mark achieving important moments in the project
6. Prepare for change - make the schedule as simple and as solid as possible so it is easy to maintain. For example if you have the team-mate who will do 4 concurrent tasks, it does not have a sense usually to model it in the schedule as 4 tasks with 25% usage of resource - usually 2 or even 1 task is enough.
7. Make phases as short as possible (1-3 months) and at the end of each has some part of visible and production work finished - yes, it comes from agile world and it works!
8. Share the schedule among all teammates - how you do it, it is up to you, but everybody should have the schedule in their vision range daily.
9. Save the baseline and track the schedule at least weekly - have a quick session with your teammates and review progress.
10. Prepare that the last 10% of task will be the worst and it will consume about 20% of your time.

I know many PMs and each of them schedule slight differently, even when they use the same MS Project - they have they own scheduling style, so to speak. The bullets below are just the guidelines and you may have your reasons to do the things differently:

• Use schedule calendars to realize (1) and personal calendars to realize (2). Tools>Change work time.
• Note who estimates too conservatively and too optimistically and make necessary corrections of their estimations (3).
• The task should not last more than 5 working days (3)
• Use dependencies between projects wherever possible - do not use constant start and end date (this approach causes usuaylly that the schedule is harder to maintain)
• When using dependecies there is quite cool option to delay or make quicker particular task - use it wherever applicable
• Very often if you request the time buffer offically you get the refusal from the stake holder - this is why the best approach is to add AT THE END of each important task group the solid task(s) like integration or unit tests with significant amount of time and ensure it is on critical section as only than it is a real bugger; you as PM are responsible for efficent usage of it during the project (4)
• MS Project gives many different ways to share the schedule among people - tasks via emails, WebAccess, EPM, Project Reader etc. I have tried most of them and I must say that still the best way is to print on paper number of copies of the schedule and pass them to all the teammates and hang it somewhere in visible place (8)
• Printing schedules in MS Project is the art itself, but there is very usuful way to do it nicely - delete all the irellevant task like the next unestimated phase (but do not save the change), go to print preview>page settings and use the option of fitting to 1 page (for small projects) or more (for big projects).
• If the schedule does not go as it is planned and the difference is significant, you must be tough enough to admit it and introduce the repair plan - do not hide the problem under the carpet, do not limit the time for tests or other following actions because any of this solutions will explode at your face later on and it will be just worse. I know it is a painful thing to explain this type of things to the stakeholders, but believe me... Even when they will angry on you, you may always tell that at least your are this type of person who can openly discuss the issue and... do not kill the messanger ;) (9)
• If the project goes better than planned, never ever promise too much... If it will be finished on time - you are the one then (10)
• Use "Resources workload" to ensure that there is no overallocation
• Using "Rosources spreadsheet" you may add cost of work and calculate easily the cost of work for the whole project
• ALWAYS, ALWAYS remember what is the target of the project and ALWAYS have it in front of your face - do not loose yourself in papers as you are not a EU clerk and do not loose yourself playing with toys as you are not a kiddo ;)

Microsoft Solution Framework - tips and tricks

I have refreshed lastly my knowledge about the MSF. I have looked backward and deep into my soul and here there is a short list of my private suggestions if you think about going into the direction...

Choose carefully MSF3 or MSF4
There is quite a big twist in Microsoft approach to the MSF lastly. When MSF3 is the loose set of good practices written on paper, MSF4 is their implementation within VSTS... some people say even that MSF has been monetized. MSF4 defines two main templates and guidance - MSF for Agile and for CMMI. There is an option to define your own process with Template Editor, but that is not an easy process.
In general...

• Option 1 - If you have small team and you want easily customize the process - MSF3 will be a good choice and set of VS Pro licenses will be fine.
• Option 2 - If you work within big corporation, in distributed geographically team, keeping a standard is a problem... you may think about MSF4 and convincing stakeholders to spend a lot of $ for VSTS installation (that is not just about buying licenses - you have servers, administrators, infrastructure - all the heave equipment).

BTW, if you are in second option and you works with open technology, you need to consider RUP and Eclipse from IBM. There funny thing to write but in first option you may do .Net projects with RUP and you may do J2EE projects with MSF, even when MSF+Visual Studio belongs to Microsoft and RUP+Eclipse belongs to IBM.

Do not be religious
You just read what MSF is about, you are very excited... Lets rock, lets put it into play...
No, no... Hold on for a sec... go for vacation... Chill down...
Whatever you do, does not do it because the paper says so. MSF is just the tool to realize the goals. Which goals? What do you want to achieve? Whatever you do, does not forget that you are about improving things.

Introduce Framework step-by-step
Anayze the current status! Do you have some well working processes? Take care about them and protect them. Do not hesitate to customize MSF, so old-well-working things stays where they are.

If something works wrong, indentify 1-3 the biggest problems and solve them using particular mechanisms from MSF. Daily builds, bug triage, zero bug bounce - these are the good candidates at the beginning... Does it work? Do people like it? It is MSF... Lets start the new project with 5 phases, but if there is project manager in Prince2 meaning, do not hestiate to unite Program and Product manager role if that is necessary.

Team model in practise
Team model in MSF is quite unique and white paper says that each role has to work in each phase. That is not totally true. Release Management comes into play rather in the final phases. Keep in touch with the guy, but does not insist on having him at each meeting and 100% engaged into the project at any stage.

The other story is User Experience fellow. The main problem is, that there is so little people with this profile on the market. In practice very often the role is taken by business analist... and that is fine. In similar way the Program Manager role is often classic Project manager and Product Manager is Sponsor of the project. As far as it works... lets leave it ;)

Use trade-offs
Trade off theory has helped me often in practise to leverage new requirements and staying assertive - nothing is for free!

- Of course we can add the functionality! What do I get in return? Extra time or person? When he will be on the board? In 2 months? Ok... When he is on board we will analyze the new functionality ;)

In very taugh times you may mention fourth dimension - quality; triangle story extended to tetrahedron (three sided piramid)...

- I may agree to add new functionality, within the same timeframe and resources, but you must approve to me on paper that you accept lower quality of the final product.

... Yes, that is just the intelectual trip ;)

>Keep the balance between the phases
If envisioning took 1 week, the planning will probably take around 1 month. If during planning you have done all the key Proof of Concepts in code, you may close the developing phase in next 1 month. Stabilizing will the next 1 month and Deployment about 1 week.

For example... It is quite common error, that when things goes wrong the stabilization time is cut off. The effect? The same time doubled or tripled is spent during Deployment. That is a dark side of Project Management that in crasis, the taught situation must be faced and not just postponed.

If you prepare the schedule in planning phase, do not expect that you will be able to close 3 next phases in 2 months and 1 week, if getting to the point since the beginnig of the project took you over 2 months - there are some exceptional situation, but at least look in the mirror and answer yourself where these exceptions truely are.

Use bug triage
I bet my surname domain on the short setence - BUG TRIAGE WORKS!

Things, which are not monitored once per a time, go into the chaos stage. Let's face it - reparing bugs is boring and painful work to do for developers. Everybody knows it. Anyway it must be done though, in the same way how you must clean your flat (at least once per a while). Project Manager must be sometimes a mommy who says: "Sweetheart... Clean your room tommorow, ok?" or "When finally you will put these dirty socks into this damm wardrobe!" :D

Having whichever Bug Tracking System (excel / customized open source project / customized SharePoint poratl with lists / commercial product / VSTS ) is at great help - anybody may quickly see what happens with bug #645.

- Hey Bart! Our CEO has looked today in our BTS and he has asked about this problem with dockable windows. Can you add him some comment about #645 and send him a link?

...and this is it - you definitely will not loos by knowing what MSF is about ;)