The functional specification or spec describes in detail how a website operates from the point of view of the user. They may touch on technical issues but only where it helps enforce the site’s functionality. They range in size, with functional specs for complex sites running to 100 pages or more.
Remember, though, that although the functional spec will naturally touch on technical elements, it is not a technical document. It should be written clearly for an audience who are not necessarily technical in background. Avoid technical language or acronyms, and if you must use them include a non-technical definition.
The exact content of a functional specification will vary from job to job but they all share some common sections. Continue reading
In the not too distant past digital agencies and their offline counterparts, marketing or advertising agencies, kept well apart. In fact digital was seen as a bit of a poor relation, with web teams sub-contracted as necessary by the traditional print agencies.
Then the ad agencies realised that the web offered a genuine, lucrative revenue stream and soon they founded digital spin-offs (they could never see at that point that online and offline could be integrated).
But since it was the traditional agencies with the pedigree, pre-existing market share and, more importantly, money they naturally took the lead. But the mistake they made was treating digital like offline media but on the web. Continue reading
For IT projects, an industry study by the Standish Group found that the average cost overrun was 43 percent while 71 percent of projects were over budget. In an agency’s environment, web project costs overruns can have a disastrous effect on the bottom line. Continue reading
Whether due to a client-agency relationship breakdown, insolvency or a random act of God, sooner or later you will be approached to take over the management of a website developed by another web agency.
So, how can you best handle this situation? Well, before you accept the contract and begin work on the site consider these 6 points…
Effective project management requires a number of tools and instead of creating your own from scratch, I’ve compiled a range of templates that you can download and adapt to your own needs. If you have any questions on how to use a particular template, please feel free to get in touch. I’ll be more than happy to help where I can.
Please note: I’ve only just created this list and will add templates daily in the coming days, so please check this page regularly.
A project relies on the joint effort of all those involved, and such a team needs a project manager who communicates on its behalf, ties everything and everyone together to deliver a successful project. But how does the project manager track and measure success whether it’s achieved at the time of closing the project, months after the project is closed or…BOTH?
The purpose of the Configuration Management Strategy is to keep an up to date record of all the project’s management and specialist products.
The objective of the strategy is to:
- Describe how and where the project’s products will be stored;
- Identify what storage and retrieval security will be put in place;
- Identify how the products and the various versions and variants of these will be identified including a naming convention;
- Describe how changes to products will be controlled.
It helps ensure that your project runs as smoothly as possible by making it easy for the project manager and others involved with the project to keep track of what happens to all of the products. It might not achieve star status like a killer app or website, but it is essential to project success and is part of quality control.
Download Configuration Management Strategy Example
A few years ago I was asked by a client to take over the project management of a website being developed by another of their suppliers, a small digital development agency. This agency had been paid up front for what was quite a complex site and eagerly set to work. Near the completion of the project they released a build for the client to test and approve. The client logged onto the UAT site and quickly fed back that the site functionality wasn’t at all what they expected and “while you’re fixing that can we have some small changes”? What followed was a barrage of confusing change requests which added more and more functionality to the site. By the time I became involved the client was at the end of their tether and the agency had spent twice as much of their fee on development work.
Had the agency scoped out the requirements for the site and recorded them in a scope document before the commencement of a project then many of their troubles would never have happened. Continue reading