Intranet Introspection: How to Keep Your Project On Track Once It Has Left the Station

Last week I covered some pointers on the bid process and how to ensure you get the right vendors coming to the table. Now let’s cover the start of your project, or what I like to call The Honeymoon Phase.

There's really no one-size-fits-all approach to developing the right Intranet solution for your business. Anyone who is telling you that may be selling a bill of goods. Sure, there are common elements and standard approaches but every component of a large Intranet project, from the process to the final product, has different variables.

A successful project means budgeting -- time, resources, and money -- to ensure you know up-front what your needs are, what the process is going to be, and how long it's going to take.

Knowing What You Need

What I've seen in my experience is that there are some organizations that are hyper-prepared in advance: they've done a full renewal strategy; they've spoken to stakeholders; they've spoken to other experts in the field; and they have a clear path in mind as to how to handle content and functionality.

On the flip side of that coin, there are organizations that have given no thought to the information architecture: they've not defined a strategy for how the Intranet is going to be used (or how it's integrating with the organization's larger goals); and they don't know who is going to handle the content or what the project governance is like.

Again, there's no right or wrong. It's just a matter of understanding that this discovery process requires an investment. For some, they invest prior to engaging a vendor; for others -- like those in the second example -- they're going to have to ensure there's enough budget allocated and time allotted to do the stakeholder engagement, content strategy, and information architecture work.

Have the Right People at the Table

There are a few things that can slow down a project. They don't exactly derail it, but they make it like watching a freight train shunt back and forth -- things are moving, but not very quickly, and nothing really goes anywhere. Eventually, the train gets rolling down the track, but those delays can add up and cause frustration.

The approval process is one of those potential challenges. You never want to design by committee, but for most projects -- especially those that can be the size and scope of an Intranet build -- you want to ensure the key stakeholders are well informed and feel well involved.

That means having the right people at the table. We know that it's hard to get executives around the table -- they have busy schedules, multiple priorities, and an investment of their time doesn't come cheap -- but it's important to have empowered decision makers in regular contact with your vendor.

And engaging the right decision makers up front helps them to understand the potential pain points, the scope of the project, and its direction. That investment of time adds up to huge savings in the long-run. Ask any home builder whether it’s easier to add windows to a blueprint or to a finished wall.

Of course, having the right people at the table means nothing if they have nothing to do.

Ensure there's a clear agenda and share it well in advance of your meetings. If there's pre-work or discussion material, make sure everyone has a chance to review it and come prepared to talk. A good vendor will help you with this. The last thing you need at the start of your project is to have a table full of C-suite stakeholders twiddling their thumbs. That will severely undermine their faith in the project and you as the project owner. This can be complemented by regular informational touchpoints: weekly status updates, meetings, shared project boards, shared project management tools like Gantt charts. Instead of designing by committee, you have empowered key members working day-to-day and arrange for broader sign off on key milestones.

A final note on this. Your project owner should have enough power to make most decisions without having to consult with the broader group. For your project to run smoothly this is a must.

Budget Effectively

A successful project isn't just about that initial financial outlay. It's also about properly budgeting time and resources. That comes from having a realistic understanding of the scope of the project, the individual requirements, and the capacity of each team to do the work.

A well-defined series of requirements is key. Through the discovery process and into the development of a Statement of Work, you should be able to define very clearly what the end result is going to contain. Sure, things change and both sides understand that, but what often derails a project is vague requirements. Vague requirements can led to a lack of alignment -- and if both sides don't fully understand what they're building, that will most certainly lead to frustration and disappointment in the end, as you'll likely have multiple views of what was supposed to be built. Investing the time really dive deep and define those requirements up front will save you an ocean of heartache later on and set clear expectations. How do you know if you’ve scored if you don’t know where the goal posts are?

Budget Time

Have a realistic understanding of how long a build of this magnitude is going to take. If you're spending up to $200,000 on a solution, don't expect to be finished in two months. It's not worth it and any gains in speed are likely to be overwhelmed by losses in quality and usefulness.

There’s an old expression which fits across nearly all industries: “Fast, Good, Cheap. Pick Two.” This is especially true on a large Intranet project. There’s many reasons you want to deploy your project quickly, but the more time you can give to this endeavour the more exceptional your solution will be. So for an Intranet solution, six to 12 months is not an unreasonable expectation. Depending on the level of complexity and what integrations might be required that number could rise to 24 or more months. This is where a solid understanding of your project comes into play. Knowledge is power after all.

Of course, there are ways you can reduce the time line: having clearly defined functionality, having a content strategy in place, performing a content audit in advance -- all of those can help.

Budget in Some Flexibility

I’ve been in the web industry since the 90’s. And I can tell you with all honesty that I’m still waiting for my first web project that went according to plan. That’s the nature of an industry that is built on change.

Of course we all want to to stick to the plan, but both sides must be reasonable about when it comes to change management. No build is 100 per cent the same upon launch as it was in concept. That's just a fact of life and while we can't know exactly what curve-balls will be thrown at us, we can make sure we're prepared for whatever comes.

If you can, arrange for a contingency of both time and money. If you can't, make sure everyone understands that sometimes, if you want to pay Peter, you're going to have to steal from Paul. Once a budget has been set, significant new requests or functionality can only come in one of two ways: as a Phase II/separate project with additional funds, or by sacrificing something previously agreed upon to make the new request work.

Any good vendor will work with you to mitigate that. At Echidna, we want to be partners with our clients and are always striving for ways to “make it work.” It’s a two-way street though and our most successful projects are with clients that understand the fluid nature of projects and have a shared commitment for finding creative solutions.

So expect changes and be open and honest with your vendor. And don’t be afraid to push your vendor to work with you on these things. You are partners after all.

Up Next?

The approval process is one of the biggest potential pain points in any project, but what's the biggest? Content. Next week, I'm going to share some tips about effectively developing an end-user focused information architecture, how to create content, and how to deal with your legacy content through migration.