This is part 3 of a series focusing on the different approaches to a successful digital project. Andrew Breese writes from a project management perspective.

The success or failure of a website is sometimes affected by a choice of project method/discipline, a technology platform, or even a vendor choice; but more often than not the real key points of difference are separate from those choices.
This post is some key points which are either often undervalued, or could be included in a project to add real value, response effectiveness, and increase the end quality. Keeping them foremost in mind can only benefit the project.

1. Create a connection early.

This is not so much to cover scope, or anything else actually related to a strict PM goals or methodology. That’s too academic. This is so that you connect personally with the client and their purpose. If you like the project and have some personal investment in the outcome, the outcome will be better. When I think of the projects I’ve enjoyed as a PM it is not the ones that had the best budget vs. effort ratios (although that is good), it was the projects where a sense of success and achievement are present. This keeps the job interesting.
Alternately if you are the client, get in front of the PM in a informal way and explain the “why”. Create that connection for them early.
Talking through the purpose is a good way to do this. A broad outline of what the project will achieve (sometimes called Critical Success Factors by our team) will set unambiguous goalposts for the project that all future action can be compared to if any questions, comments, or alternatives are raised later.

What will make this project successful?

It could be as simple as increase memberships, sell more online, or modernise branding.

2. Explain up front the process the client will experience.

It is important that the client understand what process will be followed, and that they value the process. This should be guided by a project plan if you’re at that stage, but also could be one of the first few meetings in the project. It gets you on the same page quickly. Show them when different types of inputs are needed, and talk through the deliverables. If this is not done, and the client either does not understand what will happen, or does not value the process; then the project is at real risk of going out of control.
Also remember to ask the client for input and information about how they plan to meet their delivery needs.
Sometimes this thrashes out hidden questions or assumptions.Lastly in the explanation keep the techno-jargon to a minimum, unless everyone is likely to understand them. Phrases like UAT make sense to developers, but have little relevance or meaning to most clients. Even calling it “Acceptance Testing” instead of UAT is a move in the right direction.
If you are including a step like this in your project which is highly detailed it is reasonable for this to be a paid task. The up skilling on web concepts and process is highly valuable, and if done properly can reach beyond just one website into other projects and areas for the client. It never hurts to be “web literate”.

3. Worry about the “Moving Parts” first.

A “moving part” is a piece of functionality or integration that is either difficult to do, still undefined, has not been done by the team before, or relies on an external body to be successful. The most complex moving parts might be a combination of all these factors. A moving part can negatively affect a project very quickly and can be difficult to mitigate with strategies due to the often unknown or changeable nature of them. Identify the moving parts early, chase them tenaciously, and try to limit the number of moving parts in a project. Less moving parts will make a delivery simpler, and everyone in the process will appreciate a straight forward delivery.
If a project has too many moving parts, then it probably has too much complexity and risk inherent in one delivery, and should be broken into sub-projects, each with its own plan, stages, sign-offs, etc.

4. Limit the people who sign-off to those who actually need to.

An interesting aspect of projects is that they always require multiple steps of sign-off. And like every other decision that is made in life having a few people in a decision can help avoid a bad choice, but too many people will mean nothing ever happens.   For every person involved the process the time needed will increase significantly, and there is a reason why “death by committee” is a popular phrase in IT projects. Try to get to the true owners of the sign-off.

There are generally 4 types of people who are involved in the sign-off process.

• Gatekeepers: are those who can review, find issues, and generally agree that something is plausible. I.e. They can say no, but are not authorised to say yes. A good example of a legitimate gatekeeper is any form of internal dept who must be involved in an aspect of the website. E.g. The internal IT dept of the company.
• Advisors: are those people who’s job roles will be impacted or involved in the website after it is live. These are important people to feed requirements from, advise on status and plans, and generally keep happy. An example of advisors would be the HR or marketing team of the business. They have significant needs, and will need to know if their needs are going to be met or not in advance. These people generally have a degree of sign-off in a broad sense that their needs are involved in negotiating the scope and requirements, but they are not the people who actually say yes either. Picking the lead in each area will help smooth the sign-off.
• Owners: this might be the project owners or control group, or on some projects will be department heads or even the actual business owner. They have absolute sign-off, but will (or should) be listening to their advisors and gatekeepers to check that everyone is on the same page.
• Questioners: are people who are involved in the process, but have no gatekeeper, owner, or advisor role. They are present to question, push, tug, and otherwise test that the project is going in the right direction. They often have a specialist skill set that has been identified as important in the needs or persona analysis, but do not have the power in the project to say “yes” or “no” at all. Try to keep as few of these people in the project steering team as possible. A Questioner is highly valuable,

Having clear responsibility for sign-off, and knowing that the sign-off is real is highly valuable.

5. Have an understanding of risks and delays, and talk about them.

You need to understand that both the vendor and the client may experience legitimate delays. This will happen. These might be resourcing, key decisions, content, … whatever. Plan for the stages to take time, and allow yourself a rest or freeze periods. In some methodologies a Risk Register is created to list, plan, and mitigate each risk; and the degree of energy spent on this will have to be matched to the scale of the project.
Regardless of how the risk and delays are tracked, you need a time when you critically review the expected delivery scope and timeframe to see what has changed. I’m an advocate of this especially, as most of the trouble or risk projects I’ve seen have been mainly to due having a delay, and how it was communicated. Talking through these periodically will mean that both the client and vendor are aware of the risks in advance. Therefore neither should be surprised when an extra action is required mid-project because an identified risk has changed a delivery, the timeline, or budget.

6. Be open about the budget, and be fair.

The project budget will be under consideration through the entire project. Clients want value for their money, and vendors want a good solution which is fairly priced. Sometimes there is a mismatch in attitude between what is valuable, and in these scenarios everyone needs to sit and talk through what is reasonable. Changes in scope will happen on most projects, and this means the budget will also need to change.
It is reasonable to expect discussions on budget to be sensitive, especially as budget is just one of the three drivers for a project (being a
Trinity of Time, Cost, Scope). There is an old saying that projects can be done by limiting time, budget, or scope; but you can only have control of two of the three – and the project pays for the via the third measure.E.g. When you want something done quickly and cheaply, you will often sacrifice the quality. And conversely a high quality website cannot generally be done cheaply and quickly.In the past I’ve heard stories of clients who think it is acceptable to push the scope and budget all the time, and vendors who deliver the absolute minimum without consideration of meeting needs. Both are horror stories, and generally end badly for everyone. Don’t do it.
Most of the advice above is directly or indirectly involved in communication, and having a budget for that time is important too. Most project management budgets are based upon a frequent but brief meetings, so if complex questions of budget, scope, and time arise there will need to be additional time for the management of this too. Expect that everyone’s time is valuable, and keep a focus on the success goals of the project. Not paying for the consult time on a small change, could snowball quickly if it gets out of hand. Then the cost of resolving that issue is probably going to be greater than the cost of a short initial consult.

Conclusion

If you are speaking often to your client, in plain language, and everyone focusing on having no surprises then any project is off to a great start. Getting in early on the risks is critical, but so is having a real and honest discussion about sign-off and project goals between the client and vendor. That discussion may start with scope, budget, and timeline; but may end almost anywhere, so keep talking honestly and you’re on the right path.

May all your projects run smoothly and efficiently.

Thanks to our picture source: fanpop.com

Find more in your workshop for a successful digital project:

Part 1 – taking an operational strategy approach: 6 Steps To Your Successful Digital Strategy
Part 2 – a technical viewpoint: 4 Things To Know Before Building Your Web Site
Part 4 – the creative brief: 5 Principles To Effective Web Design
Part 5 – a take on methodologies: 7 Reasons Why Waterfall Methodology Stinks