Requirements Gathering

Understanding a business from both a technical and process perspective is crucial when embarking upon a project. Whatever it is you are creating the ultimate outcome will inevitably affect a range of stakeholders. The requirements gathering phase of a project will need to cover off at the very least the following elements.

Stakeholders identification

The stakeholders are all the people and business areas that have a vested interest in a projects outcome. Documenting the requirements of stakeholders is possibly one of the most important elements of the requirements process. Whether or not it is possible to appease all requirements can be considered at a later stage, however allowing stakeholders to be heard is an important psychological management tool within a projects cycle.

To document stakeholder action you need to identify who the stakeholders are and conduct interviews either in a group or individual environment. This will allow you to garner the objectives of the person in question and also give insight into the flexibility of the stakeholders opinions and objectives. Requirements gathering is very much about the insight and balance you can gain from the understanding of all individuals involved.

Business areas and conflicting requirements

Often in a company or organisation you have multiple business areas that can have competing requirements, particularly if there are budget constraints. Documenting these requirements and potential conflicts is part of the wider stakeholder issue, but re courses to the actual areas of business within the organisation. These conflicts can be mitigated by conducting joint requirement development sessions where key members of business areas are brought into wider strategic discussions for a wider perspective of the projects goals.

It is also important to remember that the technical knowledge level of some stakeholders may be low and key points should be communicated clearly to all levels of understanding.

Efficiencies and the current environment

Having a well-documented understanding of the current situation can create a concept of where to create efficiencies and either maintain or replace existing systems of operation. This knowledge will help justify choice of operating systems and platforms.

Users

Understanding comprehensively who the end users will be, will greatly enhance the goals and objectives of the project. The users are essentially stakeholders but for the purpose of the requirements document they should be treated as a separate category because of their importance to the project. A great way to document user requirements is through the use of user generated scenarios or ‘use cases’. This really is a form of prototyping how an individual user or group of users will use the end product as a step by step process. A use case scenario is deliberately detailed and is designed to highlight and process steps that may be missed. Use cases can sometime be hypothetical or you can conduct interviews with potential product users with the help of prototyped concepts.

Technical Architecture

For a project with any depth of complexity, technical or system architecture is a requirement for documenting how the project will come into being. Like a builders blueprint the architecture groups systems of information and documents how these data sets will interact, the layers of interaction and which services both internal and external will exist where.

This can be especially important when dealing with third party service providers where there may be blind spots of visibility such as with web-service providers. Architecting how third parties interact with your data-sets and obtaining as much information as possible about these layers will assist greatly in documenting your technical road-map.

The technical architecture can also serve to highlight redundancies in business and technical processes. Because the system flow is being scrutinized areas of double handling or unnecessary complexity may be identified in the outline of the architecture. This serves to enhance efficiency in the project but also within the wider business context.

Technical architecture of a project may cover across multiple areas of an organisation that traditionally may hold information internally around the conduct of their activities. Good architecture, as a central repository of information will encourage greater conversation between departments as well as documenting company intellectual property.

It is becoming increasingly common for projects to be so large and complex that more than one architect is required to envision a project. To create a possible environment for multiple visionaries, system architecture is often layered to create manageable chunks of a larger entity.

A good system architects level of responsibilities in a wider team framework may consist of the following.

• -       Determining user requirements and the human user element when interfacing with a technical system
• -       Ensuring consistency and feasibility of these requirements within the context of the system
• -       Layering larger complex systems into manageable components for engineers and developers to work within
• -       Creating user acceptance requirements for the testing phase of the software life cycle
• -       Consistency and relevancy of release dates and upgrades.
• -       Cost benefit analysis of different software approaches

Agile officially rogue

Whilst software developers will tell you that agile as a project methodology has been around for many years, it seems in recent times it has been gaining momentum across organisation wide processes. Agile now not just for the software development cycle is being adapted to workflow processes all around the corporate land.

The philosophical shift seems to be hinged on the downfalls of visibility straight up in a projects life cycle. As any project manager knows all too well, a project is never all it seems at the outset no matter how much research is undertaken to know the ‘unknowns’. The reality is that all projects are inherently iterative and evolutionary.  Requirements change, as a product becomes a more tangible reality. Suddenly, as it all unfolds you are building a speed racer when the functionality specification calls for a unicycle.

The most difficult part of agile is not the implementation, although it does require a fundamental thought shift. The challenges arise if an organisation is producing for a client. Clients without an understanding of the agile process will require education, to let go of the reigns and signing off the ‘fixed’ nature of a traditional waterfall project.

It would seem a dash crazy for a client to commit to an open budget, time frame and no known outcome. However as agile is implemented in larger organisations this is just the request. Rather sprints of tangible, launch able elements of a larger pie are created and all knowns and unknowns are handled in a smaller more containable environment.

The other quirk of agile is the involvement of the client. In my experience many of the heartaches of client - production relations rest upon a feeling of being left out and of not understanding the process.

By taking a client on the journey as agile requires, you are letting the client feel like an important, integral part of the team. This pays itself back a thousand fold. Realistically when things aren’t all roses and lemonade the client will feel like they are part of the problem and the solution. When your on the same team it’s difficult to squabble and point fingers.

Agile also calls for conversation. The act of physically standing at a board, covered in post it notes screaming out points of the Fibonacci sequence can be quite a bonding process. It also allows every part of the team to be heard on equal and legitimate footing.

My agile role is usually the scrum master. Scrum is my preferred Agile development process. There is something satisfying about a small passionate team on the ground and running.

The role of scrum master can be split with a project manager however I find the two roles can often overlap. This can cause unnecessary complexity by providing for both. Preferably a good scrum master should be capable of the skills of a traditional project manager, such as setting up the project, tracking time, budgets and milestones.

A good scrum master is the conductor of the process, making sure the agile processes are flowing well through the team and protecting potential roadblocks during iterative sprints. It is an important shift that ideally there is no hierarchy in agile and the scrum master is not the boss of all. It is an inherent team framework working together. The scrum master just needs to keep the wolves at bay to make sure the work gets done, and that the team have everything they need to get it done. Essentially a scrum master is a project manager however working within the agile flavour.

The scrum master oversees product releases. Importantly each sprint should be a ship ready product. The release is made of sprints. Essentially you have

Product Back log // which is broken into Release Back log // which is broken into sprints

Easy…

Resources

Scrum in under 10 mins (YouTube)

Digital Functionality Specification

What?

It's a document that is technical in nature, written primarily for the development team as a guideline and reference point as to how and what they are going to build. The document should outline objectives, requirements, Information Architecture and platform delivery and break down these compartments into as much technical details as possible in order to provide a clear road map for production. The document should also outline the development lifecycle. Here is a generic example of what the document should cover. If working within an agency it is great to have a template functionality specification document as many areas of these docs can be recycled across projects. A functionality specification can be as detailed as the project requires. This usually directly correlates to the budget of the site and the time allocated to planning.

An example of a func spec framework

• Title
• Table of Contents
• Version
• Brief
• Requirements
• Objectives
• Timelines and Milestones
• The Team
• Platform Delivery
• Functional Description (all external user and programming applications and interfaces)
  • User Community (Define who the user is)
  • Administration requirements
  • Expansion Requirements (if numerous planned )
  • Support and Maintenance Agreement
  • Site Map
  • Wireframes. (This can be referenced as sometimes requires separate documentation)
  • Database Design
  • Break down of the wireframes by description and reference in detail of planned functionality in each proposed section of the site.
• User documentation
• Test plan
• Launch and Delivery
• Terminology & Appendix

Who?

A functionality specification document will primarily be used by your development team to reference the full production life cycle. It may be at your discernment to include the client in on this process particularly in regards to getting functionality sign off. This should be taken into account when writing the document, so that anything particularly technical is explained within the appendix and is referenced accordingly. The document usually proves important to the producer of the project who is the navigator of the full project lifecycle, it states objectives and creates milestones and timelines to keep track of the project. The downside with including the client in this phase may be the time spent educating them as to this process. Ideally you don't want to be too bogged down in minutiae at this stage, particularly as a functional specification is usually an evolutionary document.

Why?

The age old question... Basically because a functionality specification can save your behind. If you are contracting a third party to develop a 'back end' solution or your client is creating changes outside of scope, the functionality spec can reference this in solid documentation. It also gives your developers a clear idea of where they're heading and how they are getting there particularly if the team is diverse or geographically separated...so make them read it.

How?

A producer should ideally be the creator of the functionality spec but it needs to be in community with the entire production team. It is of course no good specifying functionality that cannot be delivered because it is outside of a teams technical capacity. The first thing to do is really flesh out how your going to deliver a project and this needs the entire teams collaboration. The functionality specification is the formalization and documentation of this process so do the groundwork and research first. If this is your first time creating a functionality spec find a template to follow as a guideline. There are numerous examples to be found online. Do not copy it as each project is unique, so be mindful that a template will most certainly not be directly applicable. Do your research, collaborate and be clear. No one is impressed by unnecessary technical jargon so don't use it unless it is absolutely required for your developers. Whilst this is a technical document it will most likely be changing hands with the client and the non-tech savvy.

The Digital Budget Checklist.

It may not be quite the federal budget but getting a costing overview for the next digital project and sticking within those parameters is rarely plain sailing. The amount of variables involved in the digital realm are many, and a lot of them are external to your control. So planning is the lucrative word at stake and it is not to be underestimated.

When either quoting or budgeting your website there are question you need to ask yourself and your team.

Who has the money?

If dealing with a client you need to assess the relative size of their business to the functionality they can both afford and require. A multi million dollar solution is both lost and unnecessary for a boutique start up, and the opposite is true as well. In the happy case of a client having the means and the need for a grand solution you need to provide it without underselling your teams skills to get the job. In most cases larger companies are happy to pay for a solid solution rather than skimp a few dollars and be uncertain of the outcome. In my experience provided you are transparent and well documented, larger companies will pay for the knowledge that your team is the best possible means to get the job done.

Functionality and Technical Specifications

Websites are evolving mediums and with each project often you can find yourself pushing the boundaries as to what is possible to create online. The best way to counteract this obstacle is by documenting functionality to the nth degree, mainly in the form of wire framing and functionality specifications (func specs). This gives your designer and developers a clear overview about what is going to be achieved, every step of the way. It also provides a document as to exactly the types of technology to be used whether it be proprietary or open source and what costs this incurs.

Budget Timings; Who your team is and what do they need?

Functionality specs and wire framing will also equip your designers and developers with the information they need to make decisions about their technical and time requirements. Particularly in the case of developers, people external to their knowledge would struggle to assess what is truly required to create a websites technical infrastructure.

Being able to breakdown your teams timings into an hourly rate and converting that to budget timings is pretty crucial to maintaining budget scope. Particularly having the technical knowledge to ascertain as to how feasible this is. In the case of a producer not having this knowledge it is important to have great communication within the team.

Externalities.

If something is outside of your control it is very good to be aware of it in order to minimize the possibilities of it impacting your project. In the digital realm the main elements that can throw a spanner in the works are as follows.

• Browser compatibility and limitations
• Third party software restrictions or changes to software outside of your control.
• Hosting issues if servers not kept in house
• Payment gateways and credit card security for e-commerce
• Changes in technology rendering some things obsolete. Flash and iphone compatibility is an excellent example of this.
• New technology that has either not undergone stringent testing or unfamiliar to the developer. This can be quite common with new e-commerce platforms that take longer to develop initially.

Client input

Everyone who has either freelanced or worked within production agencies has an opinion on client input, but the client is integral to all our businesses and it can't always be an us vs them scenario. Whilst the client shouldn't be treated as an ignoramus bad guy it is important to keep the project well documented and have milestones signed off by the client authority in order to prevent back steps and unnecessary detours along the journey. It is not uncommon for a client to suddenly request a complete back flip on functionality, and it is always powerful to have a signed off document that can either annul the whimsy or deem it outside of scope and thus budget.

Other important nuggets for consideration.

Website content - Is the client supplying and creating using a content management system or will the site be delivered populated with the content in it's entirety.

Advertising - Is there a part of the budget allocated to advertising the site and directing traffic towards it. This is also inclusive of considerations of SEO. Depending on the nature of the project sometimes it is cleaner to present this element as a separate project budget.

Payment Gateways - In the case of an e-commerce site there are many layers of fees associated with the use of various payment gateways that need to be taken into account.

Hosting - Whilst hosting is usually not a large portion of a sites budget, if a site becomes immensely popular or requires an extreme amount of bandwidth it is perhaps necessary to investigate dedicated server hosting, which can become costly.

Stock photography or shoot requirements.

Some important phases to take into account when creating a budget.

• Research and planning
• Solution design
• Design
• Front-end development
• Back-end development
• Content entry
• Testing
• Go-live

What not to ask your web designer to do

There are a few fundamental no no's in the website game that can really make or break the users experience of your site. We have compiled a list of the ultimate things of what not to do when approaching the design, development and marketing. Some of these are contentious and some you may not agree with but the tried and tested science of usability will argue otherwise, sometimes even the best looking site can be an epic fail.

The infamous splash page...

This is a page that acts as an introduction, usually graphic intense with an enter button that takes you to the remainder of the site...sexy? they can be, damaging to your sites ranking and usability? Completely. Let me explain why.

The average attention span of a common internet user upon landing on a site is a few seconds..like 2 or 3 to be exact. If your going to use this precious commodity on an entrance page containing little or no information your not going anywhere fast. You have to capture a users attention, reminding them why they are there. People use the internet for information, they don't want to be wowed with flashiness..contentious I know...you need to tell them what they want to know instantly or shazam they've clicked out of you.

Google won't rank you properly. Now there is a sentence you don't want to hear. A websites home page (the index page) is very important in how it is searched for relevant key words and content...If you have neither of these, which splash pages by definition don't your starting an a back foot miles behind the rest of the competition. To quote a fellow writer on this subject

If your web designer tries to convince you that you need a splash page; buy a large fish and slap him or her with it repeatedly"

Extreme maybe but I don't think so.

Flash for the use of good and not evil...

Flash is used to add animation, video and interactivity to websites. Flash is amazing, flash is damn cool but flash has been abused publicly and it's not pretty. I am not a flash hater, some of my best friends are flash animators and let me tell you they really push the boundaries of cool animation and web interactivity. It's when you get bad flash that it all goes a bit sour, and you not only want to tear your hair out but more importantly you give up on a site and go elsewhere.

A few things to think about before using flash.

It's not indexable by google. There are ways and means around this, like creating a HTML version of the site and delivering that to googles spiders for light reading. This does essentially mean your creating two layers of the same site. Load times for intense animation. This comes back to the 2-3 second attention span of internet users...your pushing it expecting that they will wait. Flash requires your user to have a flash plugin. Admittedly lots of people do, but then again there are always some people that don't have the plugin, and your site will not exist to them...just a grey unreadable box. Iphones don't use it...Yup a total killer to the flash community, if you want your site on the mobile fly flash will not work on an iphone.

So flash has it's downsides but because it is so damn sexy what the general consensus has been is to create hybrid sites. That is traditional websites (HTML based) with flash elements inside them. So anything that doesn't require animation is served in HTML code and anything that does is embedded in, beautiful.

Bad Navigation

It's not often hear me say limit your creativity, but on this one, do not reinvent the wheel. The way users interact with navigation is a learnt process and if you go outside their sphere of knowledge you loose. Put it up the top, make it obvious and keep it clean.

The worst, navigation elements that fly out to 3 or 4 levels and when you rollover they fail. Seriously infuriating. Navigation should never recourse into more than 3 levels and I'm being generous at that. I would suggest two levels at the most with Main navigation and sub navigation, if you need more than this, perhaps you need to investigate your Information Architecture (see next.)

Bad IA (Information Architecture)

What is IA you ask, it is Information Architecture, which seems to be an over the top way of explaining the flow of information on a site. IA is critical to a sites success and it truly is architecture in the sense of trying to deliver your message in a coherent way whilst navigating a user through a site. Things like breadcrumbs, which are a list of the pages you had to navigate to get to your current location, are great for helping a user know exactly where they are and where they need to go. Bad IA is when the user is taken to a part of the site that doesn't serve them. Like a contact page without any contact details (don't laugh it happens.)

Old Technology

It's the nature of the game, evolve or die. Sites that use obsolete technologies don't work anymore and the reason is that they were never that good in the first place. Here are some examples of things not to touch, and if your developer is using them, find that fish again and slap them with it.

Tables...this is so early 90's it pains me, but they are everywhere. Table layouts have no flexibility and can harm google ranking by the amount of code to text ratio that they require. How do you tell if your site is using tables...it's in the code so if you right click and view source, and you see things like this <table><td></td></table> your outdated. * There are some cases when tables are okay, like a data table but not for entire layouts. Frames...This is a weird one, it uses a frame to call in another HTML page. If this is used for an entire page that is wrong, if it used for things like google maps it's allowed.

Broken Links

Links that don't go anywhere and serve you a 404 not found page or some other meaningless error message. There truly is no better way to say unprofessional than to navigate a user to a page that doesn't exist.

www or no

Have you ever been to a site and left out the www and the site goes nowhere or you get an error page? This is because the domain name has not been directed correctly and can really throw users off scent. It's a good one to check and it does get overlooked.

So in a nutshell

I did consider creating a list of my top 10 worst websites (and it's quite lucrative list at that) but I didn't want to loose any friends. In summing up here is a small list of other little chestnuts to avoid

• Never resize a users browser window...that's right never, it's annoying
• Pop up's are budget, nobody likes them and most modern browsers will block them
• Don't ask for a high bandwidth or low bandwidth option on entering, you want as little obstacles as possible to get a user into the guts of a site
• Focus on content. Content is king, this is the current way of the web, have something valid to say and keep saying it. Get a copywriter on board.
• Your website must work in all modern browsers IE6,IE7, IE8 Firefox, Safari, it is unacceptable for some of these to be left out
• If you really must have music (don't recommend it) make sure it's easy to turn off

Social Media and Web 2.0
What does it Mean?

Really these two things sum up the place that the internet is currently existing in. Back in the dark ages of the 90's (because that was so long ago) websites and the internet were comparatively static entities with relatively little cross pollination and interactivity.

Now the tune is a little different, the web is all about blurring the lines between sites whether they be personal, corporate and social with quick access to information and multiple content authoring. So what does this mean.

It means everyone's doing it, the neighbors, your aunt agatha...everyone is in on the game and big corporations have exactly the same amount of leverage as the guy down the road...it really is democracy at it's finest. The guy with the most power on you tube isn't Bill Gates it's the kid playing with kittens whilst humming Mary Poppins whilst standing on his head.

In my opinion the best way to get in on the slice, and that is to get the most userplay possible is this.

• Create a community. If your site is selling something or you are a firm and you have an existing client base, use them to begin your community. Have an interface where these people can be excluded as special and interact with one another. This can be done in a myriad of ways with the likes of forums, surveys, Email Newsletters. Be careful though not to swamp the customers. You have to have something valid to say otherwise it's just pollution which is spam.
• Have something to say. Be clear about what your communicating and why you are here trying to communicate it. Social networks when used for a commercial means is truly about managing how your perceived and the message you are delivering in that network.
• Embrace social media culture, yep get twittering...or if the thought irks you pay someone else to, but be careful there is a fine line between good information and too much information, it's always weird when you see bikini shots of clients on facebook.
• Interactivity. Use interactivity wherever possible. Allow people to comment on things you've written, allow dynamic authoring (that is other people can post content), employ video, start a youtube channel, allow people to sign up to your database. Get them on a chatroll with a professional in the field, there are literally thousands of ways you can get a user to interact with your brand.

Elements of a web 2.0 site

• Search
• Links
• Dynamic Authoring
• Tags
• Extensions
• RSS
• API's (Plugins like google maps)

Cloud Computing....A Paradigm Shift

Sounds geeky but cloud computing represents a shift in how users work with technology and interact online. Basically cloud computing puts resources on the web and makes them accessible anywhere in the world.

To use an example, say your working on a presentation in Melbourne and you need to collaborate with a co-worker in Sydney. In the old paradigm you would create the presentation and email it back and forth when changes are made.

Within the context of cloud computing the presentation document exists within the cloud, that is it is hosted externally, and is accessible anywhere in the world. There is only one version of the document and each individual can make changes to the document directly in the cloud. This eliminates the need for version control as there is only one version of the document in existence, within the cloud.

Google has particularly run with the concept of cloud computing, with google documents (docs). Basically it is an interface where you can upload documents in the form of spreadsheets, presentations, forms etc and interact with real time collaboration. This is an amazing tool for any business needing to collaborate that traditionally would have been limited by time and space.

It is possible to commercially purchase cloud computing space. Apple's 'Mobile Me' is a popular concept for this. The cornerstone for mobile me is the ability to store all your documents, contacts and calendars across multiple devices and in sync.

So this is all very handy for future reference but the crux of cloud computing is that it does change the way we interact with information. Basically information is becoming in a sense one step less tangible. It is beginning to exist more in the ether than ever and global collaboration is about to spike.

This is important for digital strategy in the sense that users will expect to have more input into information more than ever, rather than being served data. Mobile learning and teaching tools will become much more common and employees once again will become much less limited by geography.

Keywords; Why they are important and how to use them

Search Engine Optimization, it's the word on the street and there is money being thrown at it left, right and centre.

The cornerstone of SEO at least I would argue is content. Content is King, repeat after me 'Content is King!'. The words you use in your site will have the most power in determining where and how you will be indexed in google. The industry name for these little chestnuts are keywords. So now that we have established this foundation, how do we know how to use them to our optimal advantage.

The first step is to do keyword research. That is to prepare a list of keywords that are relevant to your site, that will return the most conversions and have appropriate levels of competition. You may also be find a keyword niche that with incorrect spellings or a branch off your subject matter.

All Keywords are not created equal, some keywords generate traffic but no conversion, that is that the user doesn't stay and interact with the site or if the site is e-commerce, they do not purchase. This can be because the keywords are not relevant to what the user is actually searching for. Keywords also have competition, I would likely hazard a guess that the keyword 'Porn' (sorry but it is the highest searched term) would be close to impossible to get ranked on because of the sheer amount of competition.

The key (pardon the pun) is to find profitable keywords and this is done using a keyword program to research internet user data.

Keyword Country (www.keywordcountry.com) is scarily good at creating profitable lists for keyword searches. It does this by comparing data about who is currently indexed in these keywords, competition levels and even pointing you to where niche markets exist. It helps you create keyword lists by aggregating a list of thousands of possible words and than through a formula narrows these lists to a potent few.

Once you have your list of keywords that is going to send you straight to the top, you have to integrate them within your content, your url's and your page titles. It is important to use these keywords in a human fashion, that is don't start talking like a computer in order to condense as many keywords as possible into a cloud, google will be onto you....