项目管理的Glossary

If you introduce new ways of doing things to anyone, particularly if they don"t have much choice about it (such as part of their job), it"s only fair that you work with Business Users or other stakeholders to make sure they"re happy with the new way of the world.

Part of this is sensible User Centred Design, part is validation that you"re meeting their needs, and part is simple communication so that they know what you"re doing and why, before it"s all set in stone. The worst possible outcome is that the first they know about it is at the post-build testing phase - unless you like dealing with outright rebellion or sneaky subversion.

1. The business requests a change, defining detailed changes to the functional spec and perceived benefits resulting from the change.
2. The technical team analyses the detailed changes and conducts an Impact Analysis, highlighting the expected changes in costs and risks.
3. The business weigh the change"s costs/risks against its benefits and decides whether or not to go ahead and accept the change.
4. If the change is accepted, the project has a new scope, costs, timescales and risks, and the development team is no longer expected to meet the old ones.
    

Something one tasks needs from another task before it can complete. So before you can cut up the site into templates in a content management system, you"ll need the HTML templates, which will need the visual design, which will need the branding, which will need the marketing strategy etc.

Dependencies come in two major flavours:

1. End to Start, where I can"t start my work until you"ve finished yours.
2. End to End/Start to Start, where you dripfeed your deliverables to me as you get them done, so I can get on with my work. An example would be where I can get started on producing HTML templates from your visual designs as soon as you start passing them over.
    

The number of hours/days/weeks from start to finish of a piece of work. Elapsed days can"t be compressed by throwing more people at the work. An example would be obtaining a Merchant ID to accept credit cards. The bank will take the same number of days to do their due diligence, and there"s nothing you can do about it.

Alternatively, if you put several people on a job measured in man-days, elapsed days is the actual amount of time taken to do the work.

Producing wireframe layouts for a site will take a certain amount of effort. If you put two people (of either gender) on it, they"ll split the work between them and the elapsed time involved will be reduced.

The simplistic theory is that man days are fixed and are simply divisible by the number of people involved to find the elapsed time. In projects where communication is a major factor (as it is in nearly all IT projects), this doesn"t quite work - in particularly complex projects, adding people to a job may actually slow it down. This realisation was documented by Fred Brooks in The Mythical Man Month.

Discovery Phase

Is there a situation which needs a project at all? This is where you find out by conducting a needs analysis of the current situation (do people want nasally fitted fire), and finding out if there"s a possibility of getting the resources you might need.
 

Initiation Phase

This is the phase of the project where you do the initial planning, get go-ahead and (most importantly) get the budget to allow you to actually run the rest of the project.
 

Design Phase

This is when you analyse the current situation, define the end situation, and decide on solutions to get you there. Surprising though it may seem, this is usually the hardest phase, and certainly the one which takes most creative thought.

In almost all projects, the business (via the stakeholders) would first define its requirements, to clearly state what is to be built, then the technical team would define the technical solution to those requirements (ie how it is to be built). This order is essential to ensure that the project delivers against the business need - the thing which gained the project resources in the first place.

Build Phase

Now you"ve decided what you"re going to build and how, it"s time to go and do it. For junior developers, this is all they will see of a project, and more often than not, all they"ll care about.
 

Test Phase

Does what you built actually work? Does it deliver against the design? Here"s where you find out, before you launch it.
 

Launch Phase

This is where you"d train any business users, communicate to the rest of the stakeholders (including the public for Internet projects), move the site to production and register with Search Engines.
 

Evaluation Phase

So, you"re live. The site or system performs everything which the Functional Spec said it would. But does the system deliver against the business need? Will you make the sales? Will your content managers update the content within a sensible timescale? You won"t know until it"s being used. Think of this as testing for the business requirements - in many cases, this is where the next iteration starts getting designed, with changes arising out of the live learning being added to the list of functionalities which didn"t make it into scope for this one. The usual choices at evaluation are:

• Kill (it doesn"t work, it won"t work, or it"s doing damage)
• Modify (it doesn"t work as planned, but could work if changed)
• Maintain (it"s fine as it is)
• Invest/Expand (there"s greater potential than expected and it"s worth throwing more resources at it to add enhancements)

PSO is a key concept in almost all projects where IT is involved. Based on the assumption that you"d rarely do IT stuff for its own sake, and even in those cases, there are non-IT implications, it says that any substantive project will have impact in three areas:

• Process
  Almost all IT developments require a different way of working for someone. If you move replying to a site"s contact us form from freeform email to a job-based web application where admins take ownership of a contact and reply via a form, then this is a different process. Alternatively, if you"re selling products online, you"ll need to ensure that there"s a process for handling returns.
• Systems
  This is the IT bit. Inexperienced developers sometimes assume that this is the only area touched by a systems project.
• Organisation
  You"ll probably also need to organise your people differently. Introduce a new site, and it"ll need updating, so you"ll need to put some staff time into doing that, possibly by recruiting dedicated people. You"d work out how much staff time using an impact analysis, based on the new/changed processes involved. Alternatively, if you"re selling products online, you"ll need to be organised with someone to pack and ship it to the customers, and you"ll need to plan and get inventory to whoever"s going to be packing and shipping it to the customers. If you"re dealing with products with long lead times (like flowers or any complex industrial product), you"ll need to be organised to have the inventory and any production capacity and component sourcing correctly forecast a long way in advance.

The more complex the project, the more significant Process and Organisation become. Systems becomes the "easy bit" at a surprisingly small scale.

What could go wrong with the project? What could go wrong with the system once it"s live? For each thing which could go wrong, what would be the impact of it happening? How likely is it? Combine all of those and you"ve got your register of risks.

Normally you"d track these regularly through the life of the project with a red/amber/green traffic light summary. Red means that the risk is either Very likely with a medium or high impact or High impact with medium or strong likelihood. Green means Low impact and low likelihood. Amber is everything in between. Naturally, new risks are added as they"re discovered, but old risks are never removed from the register - they"ll just sit there at a comforting Green.

You"ve completed the build, and walked through the system with your stakeholders. They haven"t made any complaints during the UAT, so you think you"ve delivered what you"re being paid to deliver. But how do you know? When you ask the sponsor to be paid, how do they know? When in a year"s time, the client starts complaining about your work, and that you didn"t deliver against their requirements, how do you prove otherwise if they sue?

The only way you"ll know is if you get a signature, or a minuted meeting, or some other clear, unequivable record that whoever has authority to formally accept your work has done so. Once they"ve signed off on the work, they take all future responsibility for it being fit for purpose, so any come-back will land on their heads, not on yours.

This also applies to the design phase. Someone will have to formally agree that what you propose is what they want. Then if there"s a complaint during build of Who asked for this? This isn"t right!, you can instantly stop the argument by pointing to the signoff and say It"s signed off. If you have a problem with that, it"s nothing to do with me.

Of course, tensions arise when inappropriate people attempt to claim signoff rights (example - when the Technical Lead wants to sign off content in the absence of the project director (answer When I sign off your technical infrastructure, matey, and not a day before), or when not all of those who need to sign off do so (say if one member of a board gives signoff to an external publication when the whole board needs to). But that"s stakeholder management...

A contractually enforceable agreement on the quality of service provided. This is often used for planned uptime of a site (99.99% (or "four nines") is common - any unplanned downtime which exceeds this gets you money or other goodies back from your hosting provider), and turnaround time for support. You might also have an SLA for turnaround time of legal signoff of site content.

The point of this is that you can make firm plans around whatever the service level you"ve agreed, knowing that even if you don"t get that level of service, you"re going to get compensated (and perhaps more importantly, not blamed) for slippages.

1. Educate the sponsor to supporting the users" goals (this is the ideal outcome)
2. Support the sponsors goals (and get paid)
3. Support the users goals (and get fired)