Eli Robillard's World of Blog.

[WebMethod (Description="Retrieve the production volume for a given year and region. Returns a single integer.")]
public System.Xml.XmlDocument GetVolume(int year, string region)
{
    System.Xml.XmlDocument xd = new System.Xml.XmlDocument();
    xd.LoadXml("<root><volume>" + MyNamespace.GetVolume().ToString() + "</volume></root>");
    return xd;
}

The MyNamespace.GetVolume method returns a single value which I then pad with a descriptive tag (volume) and a root tag (root). Without the root tag I kept seeing a "root element is missing" error from the VB, and figured it meant my resultset was empty, not that it was looking for an actual element named "root." Note to people who write error messages for a living: concise is nice unless you write error messages for a living. Just two more characters and this could have read "<root> element is missing."

This is the code-behind for the button-click event from the Excel spreadsheet:

Public Sub GetVolume()

Dim objVolumeCalc As clsws_VolumeCalc
Set objVolumeCalc = New clsws_VolumeCalc
Dim lngVolume As Long
Dim objRange As Excel.Range

Application.ActiveSheet.Range("A2").Activate
Do
    If Application.ActiveCell.Value = "" Then
        Exit Do
    Else
        lngVolume = 0
        lngVolume = objVolumeCalc.wsm_GetVolume(Application.ActiveCell.Value, "CAN").Item(0).Text

        Set objRange = Application.ActiveCell.Offset(ColumnOffset:=1)
        objRange.Value = lngVolume
        objRange.Activate
        Set objRange = Application.ActiveCell.Offset(RowOffset:=1, ColumnOffset:=-1)
        objRange.Activate
    End If
Loop

End Sub

The companion article shows how to install and use the Office 2003 Web Services Toolkit to create the web service reference. This creates a proxy class in your VB code-behind to make the web service calls. The next frustrating error I received was "argument not optional." At that time my WS call looked like this:

lngVolume = objVolumeCalc.wsm_GetVolume(Application.ActiveCell.Value, "CAN")

The question being, "which argument is missing?" It was apparently the argument for the item specifier I hadn't yet added:

        lngVolume = objVolumeCalc.wsm_GetVolume(Application.ActiveCell.Value, "CAN").Item(0).Text

Happily, the string is auto-basically converted to a long, and getting this line right was the final trick to getting the spreadsheet working. What does the rest do? Well, it uses the values from cell A2 on down to populate the cells from cell B2 on down with the results of the web service calls. This code came from an article that is now otherwise outdated.

 The end-result is a form with a button that looks something like this:

At Eidenai we're working in the third milestone (M3) of a portal project for a major manufacturer. My methodology is to scope the milestone by reviewing both the planned features for M3 and the features we agreed to drop from earlier releases, identify priorities, identify available resources, break the work down into tasks, and the order the tasks according to priorities and dependencies. 

I sent the task list to our Senior PM with estimated durations, who thought the estimates were too tight. People who Project Manage full-time (e.g. PMPs) will pad tasks to allow for unplanned events. I don't like to pad, it doesn't seem like planning. I figure that if the environment is unpredictable, that's an issue and a problem to be solved. But he's right, while my estimates are accurate for each task, the total is low. A way to fix this occured to me today.

I never liked developing in open offices for the simple reason that when anyone is physically able to walk up to ask a question, they will. This is fine for some people (and expected of receptionists and the help desk), but for developers it kills productivity. Getting your thoughts back to the state they were in before an interruption takes time. On average, let's say we peg it at 20 minutes per interruption (which may be low). At that rate, every three "quick questions" kills an hour of productivity. If this happens twice or more in any given hour, that's less than 20 minutes of productive time per hour. This is why companies like Microsoft provide everyone with an office a door that closes. In software development, doors increase productivity.

Task switching takes at least twice the time of an interruption. After finishing something, there's a period of "getting away from it" (after work, how long does it take you to get out of "work mode"?), and when starting something a period of "getting into it." Let's see what happens when we account for this. Let's say Jason has two tasks to finish this afternoon, each will take two hours, and he will start at 1:00. I have one task that will take 4 hours to complete. Assuming the estimates are dead-on, who finishes first? I will, every time, and the difference will be about one hour. The difference is task-switching.

Bridging tasks across days has the same effect -- a 4-hour task split over two days will take 5 hours. This is one reason (of several) why agile methodologies can lead to higher productivity. In agile teams, the question every morning is "what will we do today?" By nature tasks don't bridge days, and agile methods therefore avoid the cost of task-switching. This makes everyone on the team more productive.

For planning, the solution is to set expectations according to the duration of tasks, the number of tasks involved, and the cost of task-switching. This adds a new type of entry to the project schedule -- the Get-In / Get-Out time (or GIN/GO time, with hard Gs). Add GIN/GO time for complex tasks which require deep thought, and less for the simple pieces. As a standard I'd suggest 20 min for GIN and 10 min for GO, for a total of 30 min for a full Task Switch. At this rate, four one-hour tasks will take 5 hrs 50 min ( GIN, task, GO/GIN, task, GO/GIN, task, GO/GIN, task) while two two-hour tasks will take 4hrs 50min (GIN, task, GO/GIN, task).

This approach assumes that the tasks are refactored. What does that mean? 1) Tasks are broken down into units that don't need to be broken further, 2) closely-related tasks have already been merged into single tasks, 3) tasks longer than a day are either further divided, or include bridge time.

This is just a start and I expect these basic ideas will evolve and be extended as time goes on. Agree? Disagree? Do you have an improvement or think the numbers are off? Tried it out? I'd love to hear your feedback.

SharePoint Advisor magazine has an excellent article by Garry Smith that covers the most important aspect of a SharePoint deployment: getting people to use it.

After you have a solid start on the structure and a plan to migrate documents, you need a plan to encourage people to continue participation. So I'll add one element to Gary's structured approach: a rewards system. Rewards can range from a "top contributors" section on the home page, to a certificate, to a night out, and can be awarded based on quantity, peer-ratings or votes. Champions are great at coming up with the specifics, the point is to address it.

Why do we need rewards systems? Most people do not learn to work in open, collaborative, sharing environments. Before we learn how to function as a team, we function as individuals. As individuals there will always be tendencies to stockpile knowledge and work in isolation. It is natural to put self-preservation before the common good. To do otherwise is an acquired trait, and it needs to be encouraged before people can experience the benefits and do it spontaneously. Experience leads to internalization. So find ways to encourage participation and get everyone contributing to a truly living hub. Evolve your team.

And check out Garry's article.

After dismissing a weak collection of complaints about SharePoint in a previous post, let's take the other side and identify some real issues (Bil has the positive). I won't rip into specific features, that would be too easy and made irrelevant with links to the third-party solutions. Instead, let's focus on the solvable, foreseeable problems that hampered the WSS 2.0 product cycle.

1. WSS 2.0 was released without a timely strategy for educating people on its use, maintenance, customisation, and extension.
Until late 2004, no comprehensive resources existed for WSS. It was left to the dev team to spread the word, and for developers to hack the platform to figure out how it works. I saw a great presentation on deploying custom site definitions at TechEd 2004, really wonderful stuff. Someone asked where the contents of that presentation were documented. The answer? They weren't, the first good resource would be the TechEd DVDs. That was the message for too many topics until good books and online resources started appearing in late 2004.

Compare this to the story of Whidbey (ASP.NET version 2.0, now in Beta 2), which already has a collection of excellent books, resources and thought leaders (e.g. the ASPInsiders) positioned to evangelize and facilitate adoption of the product. When Whidbey lands, people will know how to take advantage of its features. The SharePoint teams needs a strategy up-front that gets the same depth of knowledge into the hands of authors, speakers, and leaders. Both WSS and ASP.NET are free components of the Windows Server 2003 platform. If the purpose is to sell the platform, WSS 2.0 did not get the job done, and a failure to enable potential adopters and evangelists with knowledge is the #1 reason.

2. The built-in Site Templates and Web Parts are feature-based, not scenario-based.
The site templates intended to be used as team hubs are not usable for any scenario out-of-box. How many times have you deleted or changed the Site Image on the Default Team Site? Too many. And why is it on the definition for Blank Team Site? The team did a better job with the plentiful meeting workspaces as the "Social Meeting" and "Decision Meeting" definitions describe and meet actual scenarios. The web parts suffer a similar fate on a different level (e.g.: no built-in web parts for breadcrumb or subsite navigation) A month of scenario-driven testing or usability testing would have demonstrated this.

If the out-of-box web parts were designed for real-world scenarios, Site Template libraries would exist online. But because WSS sites tend to rely on third-party web parts for some feature or other, there are no such sites. Site templates should meet specific scenarios. There should be enough Site Templates available that they require categorization.

3. WSS 2.0 is really WSS 1.0, and it didn't help MSFT customers to market it as 2.0.
SharePoint Team Services (STS) was version 1.0, and it was a different product that happened to be in the same space. It didn't use SQL Server as a data store and used different paradigms (e.g. the dashboard). The move to ASP.NET and SQL Server was a good idea, but when the platform is a rewrite, backward compatability is an extension and not inherent, users lose features (e.g. weaker, flawed versioning) and you're attempting to recreate a file system in a database for the first time, it would be correctly called WSS version 1.0.

What will bring the platform back to solid ground? WSS 3.0 must function as a document management system. If WSS 3.0 arrives and does not improve upon both STS 1.x and NTFS for document versioning, approvals, file-access auditing, backup-restore, and granularity of security, it will be considered a failure. The point is to move users away from NTFS, Exchange Public Folders, their C: drives, and filing cabinets. Help me do that and I will help you sell platforms.

4. Social aspects of deploying a successful intranet or collaborative web were not addressed in WSS 2.0.
Granted, I wouldn't expect this to be a theme during any given development cycle. But it's been four years since SPS 2001, and most everyone I know who is successful at building great Intranets learned the hard way.

I see no Intranet, Collaboration, or SharePoint references in the Patterns and Practices Center. Elsewhere a document exists which describes how SharePoint was deployed at MSFT, but that's infrastructure and infrastructure is but a slice of a successful deployment. There's an  End-User Training Resource Kit, but it inexplicably describes scenarios (when users need help this is the one time they tend to search for specific features. Example: When you need to create a hanging indent in Word do you look up Proposals or Hanging Indent?) Tools for successful deployment are sorely lacking.

Successful deployments -- where "team site" does not become the new phrase for "data dump" -- require tools to encourage participation. Let users rate content and provide feedback. Let me measure who accesses what content, and when, without writing custom queries. Get the PAG team or Sam's team writing about the social engineering aspects of a succesful deployment. Help potential adopters achieve success.

That's it, only four. Note that these are issues of unrealized potential, and not limitations of the product. All can be overcome by people who care, and all have been overcome by people known for SharePoint expertise. SharePoint is a terrific product. It provides an excellent base to extend, and is the best application integration tool available. SharePoint is a true enterprise hub. It unifies the user interface. It reaffirms .NET as the development platform an IT shop can standardise on. It's just another ASP.NET application, so the maintenance scenario is the same for the infrastructure team. SharePoint simplifies, no question.

Could the skills be easier to learn? Yes. There is room for massive improvement with WSS 3.0. Today there are user groups and other grassroots efforts to facilitate the flow of knowledge. We're lucky in a way that the people who tend to want to master SharePoint have some interest in enabling people and facilitating the flow of knowledge. What surprises me is that the product team itself (with notable exceptions, and another) isn't as involved in the effort as it could be. At the risk of sounding corny, let's collaborate on this.

[Updates: Rewrote the 2nd last paragraph to clarify the scope of the issues and balance the discussion.] 

If I didn't already have the ideal job, I would want this first one. And if you're thinking of applying for this, let me know for two reasons: a) Eidenai is also keeping an eye out for someone to be my counterpart on the consulting (delivery) side of the business, and b) if you land it, we'll be working together.

To apply, create a profile and apply online. The first is an exclusive that you won't find listed on the MS Job Site (yet).

Technical Specialist - Portals (Toronto and Eastern Canada)
Job number: J0505-0289

In the decade ahead, we have a unique opportunity to re-ignite enthusiasm for computer-based productivity by corporations and users alike by selling the importance of information worker productivity as critical to ongoing business success.

As a Portals and Collaboration Technology Specialist (IWTS), you will be a member of a highly specialized team of worldwide sales professionals responsible for providing pre-sales technical support and accelerating technical adoption of portal and collaborative solutions built from Microsoft Information Worker Products, and Partners to Technical Decision Makers (CIOs, IT Managers, IT Professionals) and occasionally to Business Decision makers outside IT.

Responsibilitities:

• Work with the sales team and customers to understand their unique environment and demonstrate how our products and solutions will integrate to solve their business and overcome technical challenges.
• Assist The Solution Specialist – Portals and Collab in developing strategies for customer accounts and in providing deep technical support in prioritized opportunities.
• Accelerate sales opportunities through the pipeline by delivering ADS and POC’s and removing barriers to complex technical issues.
• Be recognized as the competitive technology expert as it applies to Portal and Collaborative solutions
• Work with partners (SI’s and ISV’s) to build partner technical capacity and engage customers with specific technical solutions.
• Lead technical discussions with partners and customers

Qualifications:

• Strong technical background that includes deep knowledge of our Information Worker products (Office, Share Point, CMS) and solutions based on these products.
• Strong desire to work in a dynamic, changing environment and deliver outstanding customer value and support.
• Enjoy tackling tough technical challenges and require little guidance
• Ability to effectively manage multiple high priority items simultaneously and engage in effective account planning.
• Strong presentation and solutions selling skills.
• Comfortable working with senior executives and technical decision makers (from architects to developers).
• Proven ability to apply creative solutions to problems.
• Ability to work as part of a virtual sales team with common goals but individual responsibilities/commitments
• Good knowledge of competitor offerings in the portal and collab space, particularly that of IBM.
• Previous experience in managing technical partnerships with Solution Providers or ISVs is desirable.

And Opportunity #2...

Sharepoint & InfoPath - Portal Solution Marketing Manager
Job number: J1103-0127

The Sharepoint & Infopath - Portal Solution Marketing Manager is focused on orchestrating sales and marketing planning and execution in the Canadian market place. As the product manager, you will serve as the lead evangelist promoting Microsoft's Portal offerings to the internal and external market place. You are expected to be the product and market spokesperson.

Responsibilities

Marketing Delivery

• Development of annual strategic & PR plan for Sharepoint & Infopath (Microsoft's Portal Solution).
• Act as the content, positioning, and messaging owner for Sharepoint & Infopath
• Order/develop and distribute product for GTM (Go to Market) fulfillment materials (evaluation software, sales collateral, MS Press Books) as appropriate.
• Manage marketing and T&E budgets to plan.
  

Product Knowledge & Evangelism

• Technical Expertise: Stay current on technical product knowledge by maintaining a 200 level technical knowledge on Sharepoint & Infopath.
• Serve as the internal and external spokesperson for PR/Event Delivery/Evangelism for the relevant product(s), solution(s), GTM(s).
• External events include press initiatives, public relations, seminars and solutions briefings, and high profile trade/industry events.
• Support the sales force as requested on special sales calls, customer briefings & sales readiness around the relevant product(s), solution(s), GTM(s).
• Understand how product(s) are licensed within the context of business strategy.
• Recommend and communicate relevant changes/revisions to key stakeholders as required.

Market, Competitive & Customer Analysis & Strategy Development

• Using primary or 3rd party research, monitor, analyze & report on relevant competitor(s), customer & market data, providing insights on strategic impact of competitive actions and customer & maket trends.
• Provide and present revenue forecasting and analysis for the relevant product(s) on a monthly basis.
• Actively contribute data, analysis, and strategic insights on relevant products(s), competitor(s) during mid-year review process. 

Qualifications and more can be found on this job's posting... 
 

A Top Five list of SharePoint gripes set off a chain of blogs. Paul Shaeflein wrote a good rebuttal, but the fact is that these are as much recycled, outdated gripes about MSFT as they are about SharePoint. The author blissfully ignores obvious facts or answers, which sort of undermines the whole exercise. Bil wrote the best post in the series simply by bringing the focus back to what SharePoint is.

Time to join the fray.

1. It's a crappy mish-mash of multiple technologies.
The author's argument is that Java is the same as Javascript, and since MSFT had issues with Java, it shouldn't be using Javascript. Really, go read it, that's the argument. Objecting to Javascript today is like objecting to XHTML. You would prefer PHP? VBScript? The author also expresses surprise when discovering that web development in the year 2005 requires knowledge of CSS, HTML, and XML. Seriously. In a magazine with a home page feature on the future of C++, an argument slagging the complexity of Javascript. Or maybe it's the fact that MSFT uses Javascript at all. It's hard to tell, but the author does seems convinced that something is "crappy," somewhere.

2. The development team is playing the Longhorn card.
The claim is that SharePoint features are being delayed because the dev team is waiting for Longhorn. Exactly what in Longhorn are they waiting for? Avalon (which doesn't have anything to do with SP)? Indigo (which will be released sooner than Longhorn and has less relevance than IIS7 to SP)? WinFS (which was pulled from Longhorn and properly moved back to Blackcombe)? The author fails to understand that SharePoint development is actually tied to ASP.NET, version 2 of which recently hit Beta 2, with RTM due in Fall of 2005. The SP team has plenty to work on, they're doing so, and to learn more either go to PDC, or stay in the dark and wait until RTM of SharePoint v3 in 2006. This is anexcuse to mention Longhorn and reach featured-article status, it has nothing to do with SharePoint.

3. There are two SharePoint products, which is confusing
WSS is for team sites and collaboration. SPS is for portal sites and stuff you expect of intranets. If this is still confusing, you're welcome to contact me. True, a golden rule of marketing would say they should have more distinct names (SharePoint Collaboration Server and SharePoint Intranet Server?). But hey, while we're picking nits. ASP.NET v2 will allow developers to build Web Parts for plain old web sites that aren't SharePoint sites. The horror. I see anarchy. Terror in the streets. Cats and dogs making friends. Oh wait, the technologies converge with ASP.NET v2 and SharePoint v3? Okay, that makes sense. Again, though the first argument also picked ASP.NET and VS as part of the "crappy mish-mash," the author conveniently forgets the fact that SharePoint development is tied to the platform it's written on -- ASP.NET.

4. Support for SharePoint is lacking.
No, documentation for SharePoint is lacking. It's an important difference. If documentation had been better, sooner, SharePoint's awesome user community would have been a powerful support machine, sooner. 

5. Microsoft has not stated a strategic direction for SharePoint
The author, who should be familiar with these roads, claims that no one's given him a roadmap to confirm what he should already know. Yes, reassurance is nice, but do you depend on it? From an untrustworthy behemoth like MSFT? Come on. This isn't coming from a newbie blog, it's a recognized news source (with ads for Safari and Linux on its home page). Okay so you could wait for an official position from the team or trust your own observations. Does WSS look like baby steps towards the promises of WinFS? How do you think that gap might be bridged, based on what you know of the release schedules of each? Do people have gripes about specific SharePoint scenarios? Which of these are the loudest, and historically is that an indicator that they might be solved in the next major release? What features do the competing products have that SharePoint lacks (thus inhibiting migration), and historically is this something MSFT thinks about when planning major releases?

I should have followed Bil's lead, responding to hot air isn't constructive. And once written, I'm not likely to just delete it. So here you go, let's just call it a rebuttal in support of independent thought and common sense.

[Addendum from a couple hours later. The only conclusion to this is that by making these five non-arguments, the author makes clear that he doesn't know SharePoint well enough to be complaining about its faults. Frankly, for anyone confused about the difference between WSS and SPS, or who needs better SharePoint support, just bring in someone who can guide you through, or pick a product that you prefer. If this was written on behalf of the "general public," then the author underestimates their intelligence, though I welcome arguments to the contrary.]

Today's question:

Hi Eli! Do you have a recommended tool for problem and usage reporting? I have used WebTrends in the past but I'm not sure this will work well in SP. Your advice and experience is appreciated! Michelle