Where User Experience and Information Architecture combine

In the digital world, and in a number of digital agencies today, the term
Information Architecture is being replaced with that of User Experience
consultant or expert. Despite the change in title, the work required to be done is
primarily the same but with one key difference – that being that the site/intranet
/application etc. being developed is designed from the users point of view i.e.
how we expect the user to interact with the product. In traditional IT software
development, the term Information Architect is still commonly used whereas in
digital agencies, and those focusing on the web, User Experience is now much
more common.

However, even a piece of software should be developed with the user in mind.
In fact, I believe this should be the case with any “product” – even a poorly
designed parking meter can have a big impact on a user and their impression of
the company/brand.


In the early days of the internet, it seemed that every company that existed
wanted to have an online presence irrelevant of what their customers/users
wanted. As such, many organisations put up “brochureware” sites that did
nothing more than act as a marketing tool. As the internet has evolved, and
usage increased, customers are demanding that more be made available online –
and companies are responding.

This is where the user experience and architecture of your offering comes into
play. No longer are we pushing static content out to our customers – we are
inviting them to come and interact with us, in an online environment. Come and
do your shopping, come and play games, come and do your banking. By inviting
customers to come to our sites, we’re asking them not only to engage with our
brand but also to experience the brand, and therefore as a business, we need to
ensure this experience meets their expectations and needs – and indeed, that it
meets the expectations of internal stakeholders as a result.

Defining and understanding your customers/users needs, is key in information
architecture. You have to know what information your user needs and when.
This helps in defining the structure (architecture) of the information that you’re
providing to the user. You also need to know the “how” though i.e. how are you
going to provide the information in the best way possible, and this is where you
have to be more focused on the “user experience”.

I suspect that the need to have an informational structure and also present this
to the user in an engaging and usable way, is what has resulted in the terms
Information Architecture and User Experience being used interchangeably,
although they are actually slightly separate functions. Whether you are an IA
or UX by title though, I think its fair to say that you actually need to do both
functions to be sure the product or solution meets the end users needs… but I’d
be interested to hear what others have to say…

Ready for Agile: An Introduction to Agile Development

by: Ryan Martens

“If you want to teach people a new way of thinking, don’t bother to teach them. Instead, give them a tool, the use of which will lead to a new way of thinking.”
– Buckminster Fuller, American inventor, author and visionary

What Are Agile Methods?

Agile is an organizational change tool that can lead to positive changes in your projects and programs. It is a very simple and different strategy for project management than critical path and waterfall.

The “iron triangles” shown here depict the constraints that any project must wrestle with. Waterfall software development is measured by conformance to the plan. The essential disciplines of waterfall require you to get the plan right and make the phase hand-offs of documents effective. If you get it right, waterfall can be very efficient and successful, but never early.


Agile software development is driven and measured by its ability to deliver results to the vision and value. And like waterfall, Agile requires certain disciplines to be successful. With Agile, the essential disciplines require crisp and effective cross-functional collaboration and a commitment to delivering working code in the face of small fixed resources and fixed time boxes, known as iterations. As a result, Agile projects can deliver early – as soon as the vision and value are realized.

For projects where the risks are high and the project definition is evolving, Agile’s simple empirical method delivers consistently better results, faster and with less total cost. For projects where the technical, execution and funding risks are low and the definition is well known, the waterfall process can be more time- and resource-efficient – provided you plan, you hand-off documents well, and the definition does not change during the project.


Agile is a feedback-driven paradigm for managing the design and delivery of creative, innovative, risky and complex projects. Its principles are contained in the Agile Manifesto . Its best practices include:

• Run one- to four-week iterations that deliver working, tested increments of functionality

• Make releases to customers smaller and more frequent

• Maintain the system in a state that always runs and passes automated tests

• Organize around cross-functional component teams (define, test, code & build)

• Work projects serially from a regularly evaluated and prioritized backlog

• Inspect and adapt the process and product every cycle

The Agile software development process is well depicted by the Scrum model of working on the highest priority items in concentric time-boxes including daily, iteration, release, roadmap, and vision. Organizing for Agile methods requires working in cross-functional teams of resources required to produce a complete releasable solution. This typically means people who can define, develop, test and package a component of the system. Leadership of Agile teams requires servant leadership skills. Technology to support Agile facilitates collaboration, prioritization, visibility and lightweight signaling.

How Do Teams Adopt or Trial Agile?

A vast majority of teams get started with Agile software development by adopting it on one team first. To start a pilot team, follow these on an in-flight project or new project:

1. Get the team together and get agreement to try Agile methods.

2. Declare an iteration time box, for example two weeks from this coming Monday and schedule a demo with stakeholders for the end of the iteration.

3. Prepare your top five highest priority items to get done in the two-week period. This list of items includes for each a description of the item using a story template (“For system role, provide the capability to deliver benefit”) as well as the one to three acceptances tests necessary to declare these items done.

4. Have an iteration planning meeting for about four hours wherein you task estimate these five items and discuss, with the whole team, the designs necessary to get items done-done in the two week window. (Done-done is coded, tested, user accepted and integrated into the systems.)

5. In the planning meeting, estimate your capacity in the two-week window in hours of productive time. (Typically no more than 50 percent of the wall time to available new Agile team.)

6. Use your capacity to reprioritize and shape the five items to fit into the capacity-constrained iteration. Do not ask the team to do more than the available capacity.

7. End the planning meeting by have the team come to consensus and commit to delivering some portion of the five items in working, demonstrable code at the end of two weeks.

8. Run the iteration and steer it using a daily 15-minute stand-up meeting taught in Scrum training .

9. After the iteration ends, hold the demo to get stakeholder and customer feedback on the delivered software.

10. Hold a review meeting with the team to figure out what went well and what you want to change. Ask the team if they want to keep doing Agile development or go back.

What Are the Next Steps?

There is big footnote on Agile: “It’s simple, but it changes everything.” Because the time boxes are short, it is easy to measure progress and expose issues. Agile exposes “issues” quickly and effectively. You need to be ready to work in very open and visible environment. In addition, you need to be prepared for feedback and reflection. If your team collaborates well and has the discipline to work the highest priority items in small chunks, you will not be disappointed.

Finally, if you need to think about how Agile software development can cooperate with your current waterfall world, review Michele Sliger’s Agile 2006 presentation, “The Agile/Waterfall Cooperative” .

About The Author
Ryan Martens has helped hundreds of organizations transition from traditional development processes to Agile methods and is an elected board member to the Agile Alliance, a non-profit organization that supports Agile software development. Access additional resources on transitioning to Agile at http://www.rallydev.com/agile_knowledge.jsp.

Article courtesy of Ryan Martens, ArticleCity.Com

The art of planning a project

In the second edition of their book, Brilliant Project Management, Barker & Cole offer some excellent tips on how to plan and manage projects, even what to do and say as a Project Manager. It’s an excellent book for newbies and experienced Project Managers alike – serving as a good introduction or refresher depending on your experience.

One of the chapters focuses on planning projects, which I’d like to share, mainly because it summarises, very effectively, all the key aspects that one would associate with planning projects.

The five critical elements of a good project plan as stated by Barker & Cole (2009 p16 to p25), with additions from myself:-

Project objectives and supporting key requirements
Both your clients/customers and your team need to understand the “Big Picture” and the underlying business objectives. A good understanding of what is trying to be achieved is absolutely essential as well as clarity of the project objectives. Distinguish between objectives and requirements.

Project scope
Its essential to pin down the scope and identify boundaries. Knowing exactly what is to be delivered not only helps in your planning, but also when managing change requests further down the line. Remember to identify what is out of scope as well. This usually ends up as a “Statement of Scope” or “Scope of Work” document.

Major deliverables
All tangible things should be defined and agreed up front. Check your deliverables versus the project objectives – each deliverable should relate directly or indirectly to the objectives.

Resource needs
Resist pressure to adopt unrealistic budgets or reduce identified resource needs. Be clear about the costs and be prudent – it is after all “someone elses” money and you are responsible for it! Remember to include any possible hidden “overheads” such as lighting, heating or travel expenses on projects that dictate this kind of approach.

The Project Schedule with key delivery dates
Be realistic when putting your schedule together. Don’t try to please everyone with early delivery dates if there is no hope of achieving them! Your schedule should reflect key delivery dates calculated on the time it takes to achieve the tasks that will result in a deliverable. A good schedule is dependent upon three elements:- deliverables, resources and dependencies. Keep your schedule logical and involve your team in the development of your schedule.”

This particular books is available at most bookstores (I got mine at WH Smith), the publishers and also online at Amazon. I’m sure many people will be able to add to this list, based on their personal experiences and I’d like to hear from you about it.

References:-
Barker S and Cole R (2009) Brilliant Project Managers, 2nd Ed. UK: Prentice Hall

Costs to consider when you’re preparing your project budget

Looking back on all the projects I’ve managed, I’ve found that there are usually the same types of costs being budgeted for.  So when you’re planning your next project, hopefully this checklist below will be of help.


  1. People costs. This includes internal staff, freelancers, contractors, offshore developers.
  2. Equipment costs. This can include hardware, software, machinery, projectors – anything that is purchased or hired to help deliver the project.
  3. Research costs. Many projects require up front time by the team to research appropriate solutions.
  4. Facilities that are required for use by your project team e.g. rented temporary workspace or accommodation
  5. Quality Assurance. The time and cost for this should always be included along with time and budget for any corrections/amends.
  6. Handover/deployment costs such as client or staff training, marketing, de-briefs or preparing DVDs to showcase the end product.
  7. Project specific costs – e.g. translations, the purchase of a particular font, flights, sundries
  8. Licensing/Royalties. Some projects, especially online ones, will need to cater for costs to cover licensing fees or royalties.
  9. Overheads such as lighting, heating. Sometimes this is an agreed fixed percentage per project based on the number of project hours or duration.
  10. Administrative costs e.g. additional insurances, additional telephone/internet costs for remote workers.

If there are other costs you can think of to add to the list, I’d be happy to hear from you.

Overview of the Waterfall Methodology

The Waterfall method (also known as “traditional”) is a rigid step-by-step approach to project management. Once you have completed each step within the project, you cannot go backwards. With waterfall, the entire project is planned at the beginning with each phase being given a fixed deadline. Each phase has a distinct goal.

The waterfall model derives its name from the cascading effect from one phase to the other as illustrated below. In this model each phase has a well defined start and end point, with identifiable deliverables from one phase being passed to the next phase before it can begin. Waterfall is a well documented method, with documentation being produced at every stage and it is also a very disciplined approach to a project. However, it is not suited to projects where the scope or product is vague and change control can be cumbersome and difficult.

*TRY COPERNIC DESKTOP SEARCH NOW*

FREE 30-day trial! Stop searching and FIND.
Voted best Desktop Search application. Click Here