Managing Your Intranet Development Project PART 1

Good project management is arguably the most important factor in successfully building a company portal. A well-planned and well-managed project will save money, reduce stress, and make everyone look good.
Let’s see how we efficiently manage a portal development project.

Planning

A Project Plan, like any document, is a communication tool. Its primary purpose is to clearly specify what is being done, when and at what cost to achieve the project outcomes, so the project can be managed. Always think of audience and purpose when writing anything. A key step early in your plan is to present the plan and get sign-off from the Project Sponsor.

Remember the first element of the SharePoint in Practice mantra “TIKI” is “templates.” Start with a Project Plan or Project Charter template, involve stakeholders to create a rough draft, keep it simple, and go back to refine and clarify until everyone agrees and can sign-off.
For smaller projects or those where the Project Sponsor or executive has less interest in detail, you can also use the Project Charter, which pares the plan down to just the basics.

Creating a Project Plan that is both thorough and simple is a tricky balance. To stay focused on that balance, consistently refer to the Project Management Iron Triangle. This pragmatic model has been covered extensively in project management literature, so here I’ll just remind you that the three main constraints on a project are time, money, and scope. (Scope here means the quantity and quality of work.)

The crux of it is, your project management decisions result in trade-offs between these three constraints.

For example:

• add more work and the project will take longer or cost more (more scope = more time and/or more cost);
• shorten the timeline and you need to either add more developers and/or use off-the-shelf products, or reduce how much you plan to accomplish (less time = more cost and/or less scope);
• a reduced budget mean you must do less or take longer, fitting the work in when you can or using lower cost, less skilled people (less cost = less scope and/or more time).

In simple terms, ask the Steering Committee, early and frequently, “Do you want the portal good, fast or cheap? Pick any two!” Capture their choice in the Project Plan and manage accordingly.

Project Sponsor and Steering Committee

Your company portal touches all aspects of your organization, so be sure to involve the broadest possible set of executive sponsors. First, formally recognize and name a Project Sponsor. This is the manager or executive in the organization who represents the project amongst their peers to approve budgets, manage scope, and address issues. The Sponsor is your ally and your champion, supporting project execution and keeping you honest.

To create an efficient decision-making process in your project, form a Project Steering Committee. This group includes representatives from all the key divisions of the company, especially IT, HR, Communications, and Finance.

Usually, the Steering Committee meets monthly and is chaired by the Project Sponsor. The actual task of running the meetings may fall on the shoulders of the Project Manager (you), and that is fine if the Sponsor has delegated that responsibility to you. Just make sure to keep meetings crisp, and don’t waste this group’s time.

The Steering Committee receives and reviews project status reports and change requests and is invited to provide feedback and direction on all key project decisions.

Remember that these people are just people, and they want to look good and feel good. Good project results are the best way to make the Steering Committee shine in the eyes of the corporation. Don’t waste their time but be prepared to (conscientiously) call or email a Steering Committee member between meetings if you need a quick decision or word of support.

Document Sign-Off

Getting approval signatures, or “sign-off,” of project milestones and documents is very important. Key agreements must be recorded so all project participants are able to look back at what was agreed when without relying only on memory. So, when the Project Plan (change request, the Design Document, etc.) is reviewed and approved, make sure to get a signature from the Project Sponsor and any other key stakeholders.

Documenting a milestone is not the most important reason to get ink on paper, however. People will read a document more carefully when they know they will need to sign it later, so sign-off is in part an attention-getting technique. Make sure it’s clear—in the project plan and via face-to-face and email communications (yes, you will repeat yourself)—that these documents will need formal sign-off.

As for obtaining sign-off, sometimes hunting down an executive with a signature page in your hand is the best way. However, if you don’t need a wet signature for legal or policy reasons, you can employ the simpler approach of emailing the executive with a message: “Please reply to this email to indicate approval of the attached.” Then screen capture and paste their email response onto the signature page of the document for filing.

As mentioned above, obtaining sign-off is crucial, so even though it can be a hassle, don’t get lazy on this one. (Rest assured that many other opportunities to be lazy are included elsewhere in this book.)

Managing Expectations

As Stephen Covey teaches in The 7 Habits of Highly Successful People, you must “begin with the end in mind.” You’ve clearly documented project goals and what needs to be done, by when, and how much it will cost. You have a plan that all have agreed upon and you’re done, right? Not so fast! It’s time to talk about expectations.
Throughout the project, you must constantly manage people’s expectations. In a design meeting, someone may excitedly ask, “Can we also make the font larger for announcement titles?” or an executive will suggest, “Everyone is very busy, so can we just skip the next meeting?” Your answer is always along the lines of “Yes, but there’s a tradeoff.” Remember the Project Management Iron Triangle above? Stay positive and encouraging of everyone’s ideas—you want people to be creative—but always manage your budget, scope, and timeline. This means managing expectations.

You will often hear consultants say, “under-promise and over-deliver,” which is another way of looking at expectation management. If you paint a picture that is too rosy—too optimistic—you may find yourself in trouble when things don’t go exactly as planned. By constantly, and sometimes subtly, managing the expectations of the Project Sponsor, the Steering Committee, the Design Team and others, you are keeping everyone on side with what we can realistically accomplish. (Yes, the “we” is emphasized—when done well, expectations management helps create a stronger team culture as we work together to overcome the constraints of time, budget, and schedule.

So, what do we mean by “expectations management”? We’re talking about setting appropriate expectation all project team members and the executive—what can be delivered, by when.

First, don’t just take the easy route of the pessimist and paint a picture of doom and gloom—the project team wants to hear that we can and will succeed. Do, however, stay realistic and cautious. Resist the temptation to say “yes” to everyone’s great ideas. Keep the Iron Triangle in mind always. Refer to the Project Plan and use your knowledge of SharePoint to manage change. Change always affects the project triple-constraints. Explain how resources (time and money) are finite, and so we need to proceed judiciously. If we try to do too much, no one wins.

SharePoint in Practice philosophy TIKI point #3—“Keep it Simple SharePoint”—is important in terms of handling expectations. This rule says we use out-of-the-box SharePoint as much as is practical. If you have enough development budget and time, consider including those features that may require (for example) SharePoint Workflow or JavaScript. Just be careful of scope creep.

Explain to your enthusiastic design team that out-of-the-box SharePoint solutions are easier to build and maintain by a factor of 10 or so, and when it comes time to upgrade SharePoint to a newer version, that install could well be complicated by any non-standard development work in place. Help them to choose. If it’s decided that yes, this change is worth the effort, then use the formal change request process to document the decision and get approval from the Project Sponsor.

Enjoy practical project management!
Gerry

TO BE CONTINUED…In this series, we are posting excerpts from, 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 second edition of the book is already underway so please weigh in.