Now that you know our team, it is time to get down to the real meat – we are building software here, so let’s talk about software. As I promised to keep you up to date with what is going on here at Microsoft, I decided to start a series of blog posts under the title “How do we write software at Microsoft: a PM intern’s perspective”. Expect to get a flavor of the Dev and QA prospective as well really soon!

Even though our team is small and the project lifecycle will be relatively short (just 3 months), I am sure that throughout the series you will be able to get an idea of how much energy it takes to ship a working product, and how much passion the people here put in delivering the right product on time.

OK, so let me then start the series by telling you in more details what’s been keeping me busy for the last few weeks 🙂

The Project Lifecycle

As it is with every project, we are going through a set of standard phases, each getting output from the previous and adding value to the project. Unsurprisingly, the project starts with an Analysis phase, and the basic idea is to get the scope of the project, defining what we will be doing, and what we will leave for the next versions. Next comes the planning phase, where the project roadmap is built and the important milestones that we will hit are identified. This basically gives us a great means of tracking where we are, and also enables us to react as quickly as possible if for some reason we are not on schedule. Then the project goes into a development phase, and so on.

The two major outputs from those first two phases are the Project Spec and the Project Plan. It is hard (if not impossible) to do the second without the first, so the first and most important thing a PM has to deliver is the project spec. So I will focus on the spec in this post, and next time I will give you more details on how we do project planning here.

The Analysis Phase

If you do not have a lot of experience with writing specs, you will probably be really surprised how much energy the whole team has to put in getting the spec done. Yes, the whole team – writing a spec is a team effort, and if you think that this is something just for the PM to do, consider the following:

• The Dev team needs the spec in order to start development, so that they know what to develop, and what the final result of their work should look like
• The Test team needs the spec in order to understand what the expected behavior will be, so that they know what to test
• The whole team needs the spec in order to define tasks, priorities, milestones and project roadmap, as well as give a time estimate on when the project will be delivered
• All the stakeholders need the spec in order to know what features will be delivered and when

As you see, it is impossible for a single PM (or even all the PMs working at Microsoft) to create the spec. The reason is that there are so many different people involved, that you cannot do this yourself and then just hope that other people will agree with it.  So, how do you write a proper spec at Microsoft? Here is my basic, step-by-step approach.

Step 1. Do your homework

I started by doing a lot of research in the area. I tried different things; analyzed alternatives, created proof of concept projects, etc. I spent quite some time in the role of a potential user, trying to see what I would need and how I would expect things to behave. So, I would say that the first step is to try and really understand what the project should look like by experimenting, exploring unexplored grounds. This stage is pure research, where you just try stuff out and get some experience in the area. I learned so much about the project system in VS, all the different things you need to do to extend it, what the VB runtime contains, how it is implemented, plus so many more exciting things. It turned out that while I was doing my job as a PM I got to learn so many new technical things!

Step 2. Talk to people

I talked to a lot of people. In the last few weeks I have literally had a few meetings every single day, in order to get the spec right, plus I sent dozens of emails per day. I have spent quite a lot of time with Dev, QA, PM and all the other stakeholders. I have also talked to various people from other teams outside VB when I needed technical help on something I didn’t quite understand. I think that this is one of the coolest parts of the projects – to actually understand how different people feel about the project, what is technically possible, etc.

This stage is a lot of fun, but it’s not the writing of the document itself that makes me happy. Sure, I love seeing a document get bigger and bigger, more detailed and with more things written inside. What is even more exciting, though, is the fact that as you are working on the spec, you actually understand what the project will do. You get to know every single feature in details, because this is your job. Isn’t this amazing? You are actually responsible for understanding everything, so that when people ask questions, you know the answer. I don’t know about you, but I really, really love that. At some point you have this complete picture of how the whole thing is going to work, how the different pieces will fit together, how they will interact, what the potential problems are, etc. This is one of the first things that made me start working with software, I guess – the opportunity to create, build, innovate.

Step 3. Make everyone happy

So, I spent quite some time writing the spec, and eventually I came up with a document that described what the project would do. This is where the best part came – getting all the people to agree on what I had written.

Basically, in order to get all the people to agree, you can do two things:

• Either point a gun at their heads :),
• Or conduct meetings with all of them, so that you see what is bothering them, and address each and every comment you get, so that you make sure everyone is happy with the product, and really believes the spec contains all the required information for them to start working.

We are quite humane here at Microsoft, so we prefer the second approach. We conducted a bunch of pre-spec reviews, which are basically focused-on-the-spec meetings with the stakeholders. People give their comments, different issues are discussed, and eventually people get to a mutual agreement on what we are going to be doing.

The final step to achieving stakeholder happiness is conducting a Spec Review. This is a meeting with all the stakeholders, where you get a formal approval on the spec. Everyone sits and looks at the spec, and if you have done your job well, people should not have too much feedback at this meeting, because they should have already informally singed off. Our official spec review is on Monday, so wish us good luck!

It is funny that before I came here, I thought that Microsoft (being a huge company) is all about big piles of documentation and heavy processes, weird templates, etc. And you can’t blame me; many companies actually do have those processes, even companies way smaller than Microsoft. So I was really struck when I asked “So, what template should I follow?” and the answer was “Well, whatever works for you”. Of course, there are guidelines, but you aren’t forced to follow them. They are really useful though, I learned so many new things from them… But it turns out that getting to a point where the spec is approved is really nothing more than just getting the right thing in it. Yes, getting the right things in is not too easy – for each feature developed you need to pay special attention to security, localization, performance, etc., because people are extremely cautious about all of those things. But provided you have those in, and people agree that what’s in there is enough, you can use the layout or style you prefer. I don’t know about you, but I really love this kind of freedom!

Step 4. Keep the spec up to date

After the spec review, the spec is printed and the document is marked as read-only, so that it can never be changed… You wish! :)The spec is a dynamic document and as time goes by, it is changed and updated, and it is the PM’s job to keep it up to date. The PM is responsible for understanding each change and its impact, so that the team can make the correct decision about whether the change should be made or not.

Wow, this post is already quite long, and there are so many more things to write… So I guess I will just leave the initiative to you – if you are wondering about anything in particular, don’t hesitate to ask! See you next week!