AprilR's WebLog : Project Management

One of My Favorite Things

AprilR — Thu, 23 Jul 2009 20:11:00 GMT

I just noticed myself smiling. This is one of my favorite things - the way I develop plans and proposals. I love doing the research: finding best practices, looking for the latest guidance, reviewing my old text books, reviewing notes from interviewing team and technology experts, and more. I love filtering all of this for the golden nuggets and combining it with my own knowledge and experience, making this plan or proposal better than it ever could have been before.

Too many times people rush to just do the way they think it should be done, or, asking someone else to tell them how to do it, or, just doing things the way they have always been done.

The start of a project is an incredibly busy time, but also the best opportunity to do your best to set it up for success. Don't miss the chance to pull from various sources to start it off on the right foot.

april

Moving on again!

AprilR — Tue, 16 Jun 2009 23:10:00 GMT

Hey there blog readers :) Just a quick post to let you know that I am moving again - this time to Microsoft Surface

I have been in our Developer Division for 11 years; I have had a great time working on the development of Microsoft Help 3.0, and unforgettable times working on the Visual C++ team. I've enjoyed communicating with all of you over these past few years, too!

But, I am definitely ready to take on a new challenge. I'll be utilizing my project management skills and exploring application of recently learned skills from the UW Bothell MBA program in tackling a new product, business and customer base.

SO, if you want to keep up with the latest on Help 3, make sure you subscribe to the Help 3 team blog and if you use Twitter, follow @Help3! Soon we will be posting a great guide about the new "platform."

If you want to keep up with Visual C++, you probably already know about the C++ Team Blog.

Thanks for all of your comments and support. I hope you follow me to the new world of Surface, too!

April

VC Team Release Candidate Drive Activity

AprilR — Thu, 02 Jun 2005 10:09:00 GMT

Many of you probably wonder what happens after a final Beta and before the final release. We will work to deliver a Release Candidate, which we will use to validate the resolution of Beta 2 issues that met the product "bar." Also, as we shut down the product for the Beta 2 release, there were some issues that we had to put on hold. Those issues are what the dev team have been working hard to get fixed, not just in VC but across the division. The QA team is adding any final tests and going through a few full test passes, where every test case on file is run (automated or manual). The PM team has continued evangelism efforts and now looks through the product issues to find which we can address now and which need more time to design and resolve. The division release team is watching over all of the teams very closely to make sure we are on track to shut down together and in time for a release later this year. Soon we'll start up our daily shiproom again, and I'll be giving you peeks into the types of issues we track and how we make our decisions.

-AprilR

Recall Class

AprilR — Tue, 22 Mar 2005 05:39:00 GMT

So to keep up with the project management in VC++ land, we are right now only fixing show-stopping bugs. We also call this period recall class mode, which means that we would recall the media for the bug fix. As the days of March get crossed off the calendar, we see our last few builds happening, and our last chance to find any big ~~bugs~~ defects :). We pay especially close to the risk of regressions in a main path. Many if not most of the bugs we have fixed in the past two weeks have been regressions caused by fixes we took three and four weeks ago. The team is glad to be making progress on post-Beta 2 work items as fewer and fewer people are involved in shutting down the Beta.

It helps the team's spirit that we have had a mild winter here in the Northwest - we've had many many sunny and dry days here that make it seem like it has been Spring for weeks. The bulbs are all blooming away - daffodils and such, plus tulips showing their first sign of color in my yard this afternoon. Beautiful!

april

Day 4 and Final SEPG 2005 Thoughts

AprilR — Mon, 21 Mar 2005 19:34:00 GMT

The Thursday before last was the last day of the conference. It was a choice of various half-day tutorials. For me, the first portion was about requirements development, primarily based on the Microsoft Press book "Software Requirements." Interesting and valuable refresher, but no earth-shattering insights there, at least for me.

The second one was a total blast - "Special Intelligence from the Women in Black". Four highly experienced and tremendously entertaining women, that have become known as the "Women in Black" in this circle, gave a ton of tips and tricks on how to succeed in project management and process improvement. They are my idols now. Lots of good nuggets to share from that. I even got a spy toy - an invisible ink pen with decoding marker, and my very own women in black sunglasses.

Overall I thought the SEPG was great. It was great to be around so many other project managers, think strictly about project management without any details, and to see the real successes out there with formal frameworks and good project managers in general. It was a great exposure to other parts of the software industry for me. The keynotes that I made it to were worthwhile and interesting. And the food was pretty good, too!

april

Days 2 & 3 at SEPG

AprilR — Thu, 10 Mar 2005 08:26:00 GMT

Yesterday and today were "session days" while Monday and tomorrow are "tutorial days." It's been interesting to take a step into the world of the software industry that is passionate about the formal frameworks for development and process improvement. I have met many interesting people, including Watts Humphrey. When I summarize my learnings for my team, I'll share them with you.

For now, random thoughts from my brain...

Hmmm, thinking of top take-aways.... It is sort of sad that the sort of industry standard for actual development task hours are 5-15 hours per week, with frameworks can get upwards of 20, but still, surprises me how low the number is. I do like some of the semantic differences between the way we talk at Microsoft and the way some of the rest of the industry talks. For instance "bug" versus "defect." "Defect" implies something more strong than bug; I think "bug" has become an endearing term, where as I don't think we could warm up to "defect." The other is "code review" versus "code inspection." To me, inspection makes me feel more like I'm receiving a challenge to find something wrong, whereas a review seems like a scan and nod.

Process improvement seems to be something in peoples minds along the lines of other habits people try to work on with varying success. People (okay, I'm included here) who don't eat the most nutricious meals and snacks usually know what to change yet often have trouble doing it. Smokers and heavy alocohol drinkers (I'm not included here) know that what they are doing is harmful to them, yet they continue. Um, people know that racking up credit card debt isn't good, yet the American family average is along the lines of 7-10K$, right?

What I'm trying to get at is that the number two issue our industry seems to have with implementing effective development (number one being management support) is the simple fact that people are resistant to changing habbits, even when they know it is good for them! It is perfectly logical that finding bugs earlier is cheaper. It makes sense that the better your requirements, the less time you spend coding. It makes sense that the more time you spend checking your work before checking in reduces the number of bugs/defects in test. Still, when these expert coaches in the worlds of CMM, TSP/PSP, Six Sigma, what-not, try to affect positive change that will result in higher quality, higher productivity and more effecient development cycles, the intial reaction from engineers is "Noooooooooooo!!!!!".

What are your thoughts out there? Why are we as a people so stubborn, and why are software developers, stuck somewhere between engineering and craft, seemingly especially resistant to process frameworks, even when face to face with data that shows it will pay off hugely?

april

Day 1 at SEPG 2005

AprilR — Tue, 08 Mar 2005 06:10:00 GMT

I promised to blog-as-I-go, and here's my initial thoughts on Day 1.

Today I took the tutorial on Personal Process. I liked that it was something I think I can incorporate in my work without signing our team up for TSP and CMMI. The general idea is that the sooner we find defects, the cheaper, but I think that is a no brainer. What they offered, though, were some interesting exercises to prove their point and to demonstrate the concepts. It all makes sense and has more applications than I initially thought. This was a day long session, so other than meeting folks over lunch, and in the Exhibit Hall later, I didn't do much else to report on yet. I'm sure I'll have more to say as the next few days go by.

One thing that is clear is that people were fascinated that Microsoft has people attending and presenting. They wanted many more answers than I had available, which isn't difficult because I have zero answers around our attendance there. I am attending out of my own interest in the ideas and how they can help the VC++ team. I hope tomorrow's Microsoft presentation sheds some light!

april

What's the VC++ team doing right now?

AprilR — Fri, 04 Mar 2005 08:46:00 GMT

Are you wondering what the team is up to right now? Well, along with many other teams in the Developer Division, we are feverishly working to bring you our next Beta. We've been in what we call "Ask Mode" for four weeks now and have only taken around 65 fixes in that time. We still have 50-100 bugs that we would like to fix before we ship the Beta, but we are near the point where the overhead of Ask Mode is limiting our ability to do work for the product in whole. Ask Mode is the point where teams have to "ask" to make changes - even bug fixes - to the product. We are in shut down stabilization and we evaluate every change very closely to minimize the risk to this stabilization.

There are usually two stages to Ask Mode - product team level and division level. In the former the product team (so, the VC++ team) ultimately decides which bugs can get fixed; in the latter, our team has to ask approval at the division level to make changes. At both the product team and division levels, you have a group of people making the decisions that represents each area of the group, each function of the group and in some cases the managers for the group. The division group is basically made up of the division release team and product team reps. The product team reps are generally box PMs, test managers and some dev managers. Together we work on stabilizing together so we can eventually sign off and ship!

I'll say here that I owe you a post with an overview of the milestones that we use at the present time.

To get more specific about what our team is up to, I can tell you that we tend to see the product shut down in a sensible way - the "back-end," or, code-gen and tools team tends to shut down first, with the "front-end," or language compiler, not far behind. The libraries and IDE teams tend to stabilize after the base stops moving. We meet each morning for a team triage of Ask Mode issues and decide which fixes we want to take to the division triage in the afternoon. We discuss a lot of things: the customer scenario and how common we think it is, whether or not the problem is a regression, what root cause for the problem is, the code diff for the fix, the testing coverage, the risk of the fix and the impact of not taking the fix. All of this information together with a "bug bar" helps us make our decision. A bug bar is a list of criteria that describes the kinds of bugs we should be fixing at this point of the Beta cycle.

The test team is completing a full test pass (full meaning they run every test they have including manual test cases) to report a full status of quality. We track quality on several different metrics, and that is another post I will owe you (or maybe I'll revive the Five Testers from VC to tell you about the metrics!).

april

Ready to Go - SEPG 2005 in Seattle

AprilR — Fri, 04 Mar 2005 08:20:00 GMT

Since studying project management in the latter part of my undergraduate work, as you may have noted in the Project Management Reality entry, I've tried to keep up to speed on the various professional efforts to create systems for managing software development. One of the best known groups around that work on this stuff is the Software Engineering Institute. Each year I get their advertisements for conferences, and each year there is some reason I can't make it. This year is different!

This year I am excited to be going to the SEPG conference, which happens to be conveniently located here in Seattle at the Washington State Convention Center. It is just around the corner - registration and events start Sunday. Are any of you out there going to attend? I'm interested to hear how you made your schedule choices. One thing I do know is that I am thankful that conferences such as this offer media for the full content, since inevitably you will have at least one, if not more, instances where your two favorite talks are at the same time!

Here is what I decided to target for my schedule:

Monday -

Personal Process - While I am one of the most organized people I know, I always seem to think I can get more done in less time. Oy.

Tuesday -

Avoiding a Documentation Glut
Changing within Your Organization
How to Become Your Customer's Software Provider of Choice
Pracitcal Applications of the CMMI and PMBOK
Personal Software Process for the Effective Executive
Experiencs Coaching Product Development Teams

Wednesday -

Integrating Agile Practices
Statistical Process Control
Effective Change Leaders
Learning from a Great Many Sources
Applying the Team Software Process
Developing Self Directed Teams

Thursday -

Requirements Development
Special Intelligence from the Women in Black

So it was a great time for me to start a blog last month, so I can share all of my insights about the conference with you as I go through it. I'm ready to go!

april

Project Management Reality

AprilR — Sat, 26 Feb 2005 08:15:00 GMT

Warning: This post is more of an editorial than information sharing. This was the number one topic on my mind this week (aside from reading all of your great feedback!).

In my experience it seems that all ongoing or repetitive projects go through cycles with swings from very-process-intensive development periods to forget-process-lets-get-things-done periods. I find it similar to the moves we frequently see from centralized teams and processes to distributed versions of the same. That perfect balance - that which allows us to arrive at our goal on a predicted date while exactly meeting our requirements, all for the lowest cost in resources and in the shortest time - is the project manager's Holy Grail. Anyone who has taken Project Management 101 knows, however, that there is an eternal triangular battle when managing a project. Depending on who you talk to, the exact names of each side and middle of the triangle vary, but generally you can consider the sides to be: time (schedule...), cost (dollars, people...), quality (scope, level of excellence...). You can only optimize on two sides at any given time. What they don't typically talk about, though, is the method to the madness of project management - the balance between process and productivity and its impact on morale and how to handle project realities.

The reason I chose to blog on this topic today is because this is what I'm spending a significant amount of time working through, on two fronts: shutting down our current product (2005, a.k.a. Whidbey) and thinking of how we can improve our next development experience. With regards to Whidbey, there are forces pulling the project in either of two directions: take more time to shut down, or, get the product released and into customers' hands sooner than later. With regards to our releases after the 2005 version, this work is in regards to that balance I mentioned above - the best balance between tightening up our development processes with empowering and trusting people to really use their creativity and intelligence to do the right things.

Theories, Methods and Reality

There are so many theories on the "right" way to manage projects, and a large number of those specific to software development projects. There are of course many pragmatic methods (I'm currently reading about SCRUM). As with a lot of theories, and some methods, while we can do our best to carry out the best intentions of the theories, we often face the realities that make the process or method a challenge. The proud project manager will respond here with "a good process or method will be resiliant to reality." To that I will politely respond "pthhhhhh." Even the best running process around can be derailed by realities. Sometimes the best process or method can even drive down team morale!

What I didn't (I argue couldn't) learn in my undergraduate work is how to handle realities. There was definitely content around managing people and teams, along with risk management and the like, but it really didn't prepare me for the day to day project and people realities that seem to come primarily from experience: really being able to work with unknowns, handling the massive flow of information, dealing with unexpected problems (too minor to call "risks"), the spectrum of human issues, circular dependencies, managing without authority, staying productive despite dealing with ineffective people, the Murphy's Law where everything will fall apart at once if at all possible, the other Dilbert-like moments (and balancing all of this with your non-work life), and so on.

You have to learn how to work with your project with much grace and flexibility, diplomacy and patience, and, of course, a great sense of humor. This is why you need humans - not just processes and methods, software packages and tools - managing projects.

april