Be a sport and click on this link:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5552696499
Then make a generous bid. If you'll win, you'll get an hour (or more) of help from a .NET guru/celebrity (or possibly me). But more, you'll also be helping Tsunami relief efforts.
The top bid gets to pick their consultant. Then next, and so on and so on. If you are in southern Ontario, and you get me, I'll make it up to you by coming to your office - for a whole day, hang out, and bring donuts. What will I do? I can tell you everything I know about Visual Studio Team System (breaking all kinds of NDA rules, etc.), try to convince you to use data sets, do some code reviews, help debug something nasty, defrag your hard drive, organize your mp3's, tell you what DataGrid girl is really like, whatever.
I'm visiting Vancouver, Calgary, Ottawa, Montreal over the next 3 months so if you live/work near there, my offer stands, pending my schedule. I'll also be in Orlando possibly in June (for TechEd), LA in Sept (for PDC), and Chicago in August, so ditto on those as well.
For more info on how it all works....
http://www.stephenforte.net/owdasblog/#a61b646aa-ca24-47ef-b013-012bf852f79d
And finally, special thanks to the other RD's who are volunteering their time (especially all those fellow Canadians). Last but not least, special thanks to Stephen Forte and Julia Lerman for organizing this.
I just got back from Ottawa, where last night I was speaking to the Ottawa .NET community about Visual Studio Tools for Office. (more on that later).
I wasn't surprised by the Grep Cup weekend inflated hotel rates, but I was surprised to find a “2.8% DMF Fee” on my hotel bill (on top of the 15% worth of federal and provincial taxes). Upon request, I was informed that this was a “Destination Marketing Fee” which goes to fund marketing efforts to promote tourism in the area. Various Ontario tourism centers (including Hamilton - go figure?) have been lobbying the provincial governments since post 9/11 in an effort for them to allow a tax (a real tax, not a fee) for the same purpose. This past summer however, the hotels decided that this was going nowhere so they decided to start collecting (on a voluntary basis) a fee (not a real tax).
Maybe it's just me, but I'm thinking the best way to attract people to your city is not to put a sneaky “DMF Fee” charge on those same people's hotel bill when they come to visit you and hope they don't ask about it. Even worst, because it's a fee charged by the hotel, and not a real tax - guess what - you pay tax on the DMF Fee. Icarumba! It turns out it's voluntary fee and not hotels collect it. The front desk staff sensed I was not pleased about being asked to pay for marketing fees on top of my room rate so they quickly waived the fee. But I wonder how many people willing pay this?
This all reminds me very much about requirements management and software development. Often, people, usually too close to the problem, design features into software that doesn't meet the requirements of the user. Take for example those goofy glyphs on the Lotus Notes login window. What about clippy? Is that satisfying anybody's requirements - or is it just pissing you off? With all of our best intentions, it is extremely important that we take the time to perform reality checks on what we are building against the requirements of our users.
Now to bring it all home. Do users really want to do their work in a web browser? Browsers are great for wandering and finding stuff, but do they want to see the value of their stock portfolio in a browser? You need to find the best environment for the job your users are trying to accomplish. If somebody is accustomed to using Excel to aggregate a bunch of their financial information, then maybe Visual Studio Tools for Office is the right tool for that job. While writing applications in Excel isn't exactly new, with VSTO you have the integration with the .NET Framework, Web Services, and the smart client deployment model, you can apply all professional development skills you have at your disposal to creating applications with Word & Excel. And don't worry, I have yet to see clippy show up in Visual Studio Office projects.
In case you missed it, in this
article key microsoft executives are quoted as saying that Whidbey and Yukon are still slated to ship together but that won't be by end of June as earlier stated. They are now estimating that “summer” is a better statement of expected arrival. This may align itself nicely with the PDC 2005 September date. It sounds like both teams blame each other, but really, a lesson can be learned here for all of us: Cross product integration means longer delivery cycles. This is going to be a tough nut for our industry to crack moving forward, not just Microsoft. Is that what SOA promises?
What does project management, test management, defect tracking, build servers, methodology, automated testing, code coverage, and software diagramming have to do with Halo 2? I'm not sure really, but if you want both - then you need to come to the Toronto Visual Basic User Group meeting tomorrow night. I'll be doing a “powerpoint free” drive through of Visual Studio Team System AND raffling off an xbox console and a copy of Halo 2, worth about $270. More details here:
http://www.tvbug.com/
Risk is bad. But it doesn't have to kill you if you acknowledge, plan for and manage it. The most important part of risk management is to avoid the evil consequences as soon as you can in your project. Having risks show up the day before a delivery date (or later) is really really bad.
Both the Rational Unified Process and the Microsoft Solution Framework do good jobs at addressing perhaps one of the most important project management practices. I recommend to clients to make risk management a part of their team meetings - weekly if not more often. As a team, we need to identify, analyze and prioritize risks so that we can plan to deal with them effectively.
As part of identifying and analyzing risks is to accurate assess the consequences of the risk should it happen, and while this might seem silly, an accurate description of how we know the risk has turned into a problem. That may be a drop dead date, or some other description.
A good way to prioritize risks (using MSF) is to rank the impact of a risk should it actually happen. Combine that with a probability of the risk occurring and multiple them you get a probable impact or in MSF terms, Exposure. Ranking by Exposure will help you quickly identify what risks you should spend some resources on trying to mitigate.
All of this is described in more detail in the MSF Risk Management Discipline v. 1.1 pdf.
You can also download a couple of nice spreadsheets as part of the MSF Sample Project Lifecycle Deliverables which includes a huge array of other types of documents related to MSF. But I recommend starting with the Simple Risk Assessment Tool.xls at the very least.