In 2010, at work, plans include:

• Server refresh (hopefully with a lot of virtualization)
  • New Citrix environment / upgrade
  • Re-vamp intranet/website test server configuration
  • Symantec upgrade
• SharePoint 2007 or 2010 deployment
• Altiris Management Suite deployment / configuration
• Disaster recovery project
• Information security project
• User training project
• SOX compliance process review

Those are the main things, composed of many many little things.

I hope to have more to post soon.

It shows “when I closed without saving” – a gentle, user-friendly reminder to save.

Checked in at the hotel, registered for the conference, and picked up materials from the Moscone Center.  The schwag so far includes an awesome backpack, a pen, and two t-shirts (the green one you get if you are registered as a VMUG member).

Heading out later for the VMWorld Extravanganza at the Thirsty Bear.

Meanwhile, posting photos of interesting on Flickr.

1. DEFINE
2. PLAN
3. EXECUTE –> MONITOR –> ADJUST     (loop)
4. COMPLETE
5. EVALUATE
6. CELEBRATE

It seems that most project stages / lifecycles are very close to this definition.

One bit of wisdom from the instructor:  Plans are worthless – planning is essential.

S – SPECIFIC

M – MEASURABLE

A – AGREED-UPON

R – REALISTIC

T – TIME-FRAMED

Looks like this meme is pretty common in the project management world.   I doubt I can add much to it that you couldn’t google yourself.    I did like the instructor’s definition of realistic:  gently challenging.

I did also run across an article which questioned whether the SMART goal theory was the best, compared to Locke’s goal setting theory, and another article extending the concept of SMART goal setting.

These lists are really starting to remind me of the infamous Alec Baldwin “Always Be Closing” speech from Glengarry Glen Ross (it’s 7 minutes and filled with F-bombs, but well worth it)…

1. Set a goal.
2. Determine the project objectives.
3. Establish checkpoints, activities, relationships, and time estimates.
4. Draw a picture of the project schedule.
5. Direct people individually and as a project team.
6. Reinforce the commitment and excitement of the project team.
7. Keep everyone connected with the project informed.
8. Build agreements that vitalize team members.
9. Empower yourself and others on the project team.
10. Encourage risk taking and creativity.

TechRepublic has a handy printable poster and worksheet of this list, if you happen to be a member.

It looks like this list may originally come from a book called Checkered Flag Projects by W. Alan Randolph and Barry Z. Posner, which is preview-able partially at Google Books.  The book goes into a chapter worth of detail for each point.

A ComputerWorld article has an alternative view of the Ten Commandments for Successful Project Management.  My favorite:  II: Thou Shalt Not Suffer a Fat Team.

1. Something must be done which has not been done before.
2. The undertaking ends with a specific accomplishment.
3. The required activity has a beginning, an end, and a schedule for completion.
4. Resources are limited.
5. Other people are involved on an ad hoc basis.
6. Phases and activities are sequenced.

More details on each point are listed at the above linked sites.

“Before I built a wall I’d ask to know what I was walling in or walling out.”
–Robert Frost

If you’re stuck at an airport that charges for Internet connections, here’s a solution: Go to the gift shop and ask for a a free Wi-Fi pass.

As one should for any major life decisions (or minor), I consulted Google.  I wondered, “Is it too late for me to learn programming?”  This was an interesting query because Google’s query suggestions upon typing “is it too late for me to” thought I was asking “Is it too late for me to go to medical school?” or “Is it too late for me to become a doctor?”  I have been watching House lately, so I did actually consider that as an option momentarily.

The wisdom of Google overwhelmingly answered, NO, it is not too late, and encouraged me to learn programming.  “What should I start with?” I implored further.  And the consensus was Python, favorite of XKCD.  Certainly a worthy endeavor, but I wondered if I should be more SharePoint specific in my plan?   After all, this calls for .NET development.

In general, the internets tell me that to be a SharePoint developer, you should know these things:

• Get your MCSD (Microsoft Certified Solution Developer) – five exams on .NET (Visual Basic or C#), and XML services.
• Learn VB or C# .NET
• Also learn C++
• Understand the .NET framework
• Understand Web services, ADO.NET, XML/XSLT, and Windows/IIS security
• Understand SQL server
• Learn ASP .NET development and be a good .NET developer
• Learn the SharePoint object model
• Learn CAML (Collaborative Application Markup Language)

The start of this process, for a non-developer, is learning VB.NET or C#.NET (I’m going to start with C#).  I can probably start at Microsoft’s Web Development for Beginners site.

Too bad I can’t download all this Matrix-style. 

However, we ran into an issue.  When anyone opens the document in the document library, it opens as read-only, regardless of permissions.  The only way to update it is to save the file locally and then upload it (after which it only opens as read-only).  As it turns out, this is a Microsoft bug (KB 870853) having to do with Office 2003 (we are on Windows XP with Office 2003 and IE 7).

Found recommendations for fixing this bug include:

• Editing the registry (HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\OpenDocumentsReadWriteWhileBrowsing = 1)
• Changing the Check Out Settings (Go into the Sharepoint > Shared Document > Settings > Document Lirbry Settings > versioning Settings > Require Check Out from Yes to NO)
• Changing the file options (My Computer > Tools > Folder Options > File Types > Select .xls > Advanced > De-select ‘Browse in same window)
• Opening the file a different way (Edit with…)

For our situation, none of these will work, as they either require changes to the user’s PC’s, or a learning curve (however slight) which we’d like to avoid.  We need SharePoint to be thought of as easy – we don’t want to spoil its image before we’ve even deployed it.

So, for now, we will have to wait until we deploy SharePoint 2007 before we can use document libraries efficiently.