This is PART 2 of a series, continued from PART 1.
Reliable project status reporting is one of the most effective habits of a well-run project. When planning your project, plan to produce weekly or bi-weekly status reports to distribute to the Steering Committee and other interested stakeholders. The status report is a short (1-2 page) format that quickly and colorfully shows the pulse of the project: what we are working on, what we need to resolve, and the current state of schedule and budget.
The status report lets everyone know what’s up with the project, but there’s more! I have discovered over the years that a big added value of regular status reporting is to remind me (the Project Manager) of next steps and keep me cognizant of budget and schedule.
Use your routine project status report as a regularly scheduled drumbeat of accountability that keeps you and everyone else on track and aligned with what was agreed in the Project Plan.
Change is inevitable. When writing the Project Plan, we do our best to foresee what will happen and how the project will go, but that is never entirely accurate. Embrace this fact. Accepting the imperfection of your ability to see exactly what’s coming frees you to develop a project plan that is not stuck in the paralysis of analysis. Include change control as part of the plan from the outset so you can move forward efficiently.
Set expectations and train the Steering Committee and the Project Sponsor that any change in the project, even if it is just a clarification and even if it doesn’t affect budget or schedule, will be documented with a formal change request process. Here again, attitude is important. The change request is planned and presented as a communication tool. A well-written change request helps the Project Manager quantify and clarify the impacts of every change. It also uses a standard structure that summarizes the impacts, so the Sponsor and Steering Committee can understand the change and make good decisions. Asking for sign-off of every change keeps the responsibility for project decisions where it belongs—with the Project Sponsor supported by the Steering Committee.
The milestone when the new portal is complete and available to all users is called “Go-Live,” “Launch,” or the “cut-over date.” This is a key milestone, obviously, with a lot going on.
Referring to the Go-Live Plan template, you will see communication, technical, and training tasks connected to this event.
If possible, schedule your Go-Live date to be a Monday, so you can work on final steps over the weekend, especially final migration and menus. The Monday timing also imparts a “fresh start” feeling, which can be very effective.
When your organization doesn’t really have down time—for example, the operation is open all weekend—you may need to organize and communicate some “gray area” time, when the new portal will be in the process of being implemented and old systems might still be available.
Well-timed communications are designed to keep stakeholders and the broader user base informed of what’s going on and when. There are few things people like less than a surprise when they are trying to work. You will find communications templates in the above Go-Live Plan. Note the attempt to be clear yet brief. This is challenging, so each communique starts with a brief sentence or paragraph that summarizes the critical information, and then proceeds to details, usually bulleted. You will also note that our Portal Purpose Statement is frequently reiterated (more about that in Chapter 3).
The Technical Tricks of Go-Live
The technical side of launching the company portal can be complicated. This process must be carefully planned and managed to minimize disruption and corporate confusion. Again, refer to the Go-Live Plan template and consider:
- Migration: Is content completely migrated? Has metadata been set? Has a search full crawl run since content migration completed, so that the new content is searchable? If wiki pages were migrated, have all links been updated to point to the new site content?
- Theme: It is easy to change the SharePoint theme (colors, font, and Oslo vs Seattle layout). What makes this easy, of course, is our SharePoint in Practice KISS mentality, and therefore the use of standard templates without much programming involved. One potential challenge is changing from a Seattle theme, which has a Quick Launch on the left and a top menu, to Oslo style, which (strangely) eliminates the top menu and moves the left nav to the top of the page.
- Home Page: If you are building a site where the address remains the same—building in situ—then you can build the new home page during the development phase, and just before launch, use the Wiki Page command “Set as Home Page” to replace the old page with new.
- If you will be using a new web address, you will need to involve the technical or IT team to switch DNS settings. This process can take up to 48 hours, so plan ahead.
- Menus: When developing a SharePoint portal on top of an existing site, the switch to a new home page is simple. Not so with menus. As soon as you start to create a new top menu or the Quick Launch (left nav) menu, you run the risk of changing the behavior of the existing site before you or the users are ready. Consider the impacts carefully. You may find it best to build the menu in Managed Metadata in advance and deploy at the last minute, or you may just have all your menus and links in a file suitable for copy-paste and build the menus as part of the Go-Live activities.
- Training: You have been training your development team and executives throughout the project, and now is the time to get the rest of the company up to speed. If you expect to have a company portal that is heavily used by a broad user base for advanced document management and intense collaboration, plan some significant training. If, on the other hand, this will be a system where most people need minimal training, a Go-Live Webinar will be enough. This webinar is offered to all staff. See Go-Live Webinar in Chapter 9 for more details.
- Go-Live Contest: An effective training and engagement method is to develop a SharePoint Survey in a contest format. This “go-live contest” encourages users to walk through the new portal and develop basic skills training. This contest is mentioned here for completeness, and details can be found in Go-Live Contest in Chapter 6.
### END OF CHAPTER 2 ### STAY TUNED FOR CHAPTER 3 OF SHAREPOINT IN PRACTICE ###
TO BE CONTINUED…In this series, we are posting and expanding on the concepts in the SharePoint in Practice book.
Please comment below: Do these concepts make sense to you? What are we missing? The 2nd edition of the book is already underway so please weigh in.