If you have been through an Intranet implementation you will appreciate that implementing a successful Intranet project requires a unique set of skills. Several roles will need to work in unison to ensure the continued success of the platform.

The architect, The client side project manager, the implementation side project manager, the business analyst, the developer, the infrastructure specialist, and many more will come together to shape the new intranet experience for the organisation.

Often at the initial meet and greet I receive the question about what project management methodology to use. And I don’t have a silver bullet answer. Instead it always is “it depends…”

An Intranet implementation project, like any information management project, requires a very versatile approach based on the actual requirements and organisational culture. So let’s have a closer look at the different methodologies and factors that will determine the best approach:

Key methodology traits

For this exercise I will be overly simplistic and split the common methodologies into two camps. The structured sdlc camp and the agile camp. Each has a set of key considerations that will help determine the best approach.

Waterfall, structured SDLC

This used to be the bible for software development projects up until the 21st century changed the game. This approach relies heavily on upfront requirements gathering, analysis & design. Controlled Scope, set expectations and highly specific documentation. To ensure a waterfall project (one phase comes after the next and there is no going back) is successful a huge amount of effort is invested in the early stages and the A&D component can easily cost 1/3 of the overall project.

The benefit in this approach lies in the structure and process.  In a perfect world, everybody has a clear understanding of the expectations, deliverables and outcomes of the project. Change in scope is managed through change requests and the customer gets exactly what they paid for.

The problem with this approach lies in the time it takes to get it right, the fact that you never get it right anyway and lack of flexibility in adapting to the rapid change organisations are undergoing today. By the time a waterfall project is rolled out, the solution often has been superseded by new technology on the market. Also, while the customer gets what they paid for, too often it is not actually what they need… users don’t know what they don’t know. This simple mantra has been proven true on EVERY Intranet project I have been involved in. So how can a customer ever specify their needs to a degree required for a technical specification when they have no clue what those needs really are?

Agile, Kanban, Scrum

That’s where Agile methodologies come to the rescue. Or do they?

In the agile world, we can easily adapt to change. We can re-prioritise functionality and easily bring work packets forward if the current business needs are better served that way. We can drop functionality altogether if it suddenly is superseded by new tools, add-ons or plugins. We can get results faster and see progress faster because we deliver individual chunks of work in fully tested iterations and roll them out in waves.

So if this is such a perfect world why don’t we all chant the Agile mantra day and night?

Because being Agile is not easy… Customers want to know upfront how much their project will cost and how much functionality will be included in that price. And no, doing it agile does NOT mean it’s going to be cheaper. Instead it does mean that the customer is most likely to get more value for their money. And that is where the true power of Agile lies.

It does not mean that you can save on analysis, documentation and design. Instead you ensure that each wave (sprint,chunk,packet) of functionality encapsulates the design & documentation components. That way you don’t document features too early on and then see them dropped from the project due to external constraints.

Overall, agile methodologies, when implemented properly without cutting corners, have proven to deliver more value at a reduced overall cost in a faster time frame.

Hybrid Prototyping

And then there is my favourite for Intranet projects. The prototype driven hybrid approach. In this approach you still spend a decent amount on initial A&D (about 10% of project budget) and then start designing a live prototype. Using this prototype you then gather more requirements, experiment with how users interact with new features and get the user base involved very early in the design stage. Training does not happen at the end of the project, but instead on the first day of A&D!!!

You get the users involved in the actual build of the Intranet solution and on the go live date they don’t only use the new solution but instead own the solution outright.

This approach takes the “they don’t know what they don’t know” issue head on. The users will be able to introduce new functionality themselves. They will have full control over how the Intranet will help their day to day lives and can even come up with brand new ways that the platform could be leveraged to drive transformational change in the organisation. The overall project cost will be a fraction of what a waterfall implementation would have cost and the users will receive new capabilities on a weekly and monthly basis, and not at the end of the project schedule.

So let’s all use the hybrid prototyping approach!!!

If it were that easy 🙂 There are other factors to consider. Especially around development needs, change management, organisational culture and resource availability:

Will the solution require heaps of custom development, or can it leverage existing functionality and capabilities in a base platform? The more development is required, the more structured the approach will need to be and methodologies such as Scrum become interesting that are geared at a team of developers delivering functionality in sprints.

Is the organisation ready for a new way of collaborating, communicating and sharing of information? Probably not. So throwing a bunch of random users into a training program early on is not necessarily going to have the desired impact. Is the organisational culture still focussed on “Knowledge is Power”? Are staff working heavily in silos and don’t actually need to collaborate to do a great job? Both these considerations will require a different approach to how the project will be structured.

And then there is the biggest consideration: Will staff have the time to dedicate to the project? Does the organisation have a full time position dedicated only to the Intranet project? Do the stakeholders and their delegates have 10-12 hours a week available to ensure the success of the project? And I mean dedicated business hours. Not on-top of the 45 hours they already are struggling with. Too often,the answer is no, no, no.

Decision Points

So what’s the best approach then? That’s where we need to get a bit inventive with the actual methodology approach. Look at it like a lever that you can push from one extreme to the other.

If the organisation is heavily entrenched in rigid structures, has little or no time to spare for the project and expects everything to be delivered within a set in stone budget, then pull the lever to the far left: waterfall model. This approach will ensure you can be very clear about the functionality being delivered, the costs involved in terms of development and set expectations in terms of project deliverables and timelines early on. The customer just wants to receive a finished product. So start documenting what that finished product will look like.

If the organisation can’t spare the required man-hours for a prototyping approach but is willing to be flexible on functionality and (within reason) budget, and can free up a few hours a week at least for the stakeholders to get involved in the project, then agile methodologies like Kanban and Scrum become interesting, depending on how much custom development is involved. Scrum is better suited to teams of 3-5 developers, Kanban is more nimble and suitable for smaller project teams where possibly only one developer is required.

If the organisation is willing to embrace the new technology full steam ahead, has a change management program in place, or is willing to put one in place as part of the bigger picture, and staff from all levels, C-level through to interns are willing to do whatever it takes to make it a success, then hybrid prototyping approaches will have the potential to deliver exceptional results.


So the next time you get asked the million dollar question “What is the best project management approach for Intranet projects” the best answer remains: “It depends…”


Leave a Reply