Project Management
See also Problem Solving using the System Development Life Cycle
When solving a large, expensive and complicated information problem with many people involved, it is wise to treat the process as a project.
A Project is a series of steps designed to coordinate the achievement a specific goal. Its steps are much like those involved with problem solving. It usually involves many people and therefore needs effective planning and coordination. It is temporary, with a definite start and end point. It has fixed time and resources (money, people and equipment) available for its completion.
The project provides a structured series of steps to ensure the information system is effectively planned, designed, created, put into operation and kept in operation.
Project mangement steps are:- Concept: a rough outline of the project's aims and methods
- Development: A more accurate plan of the project's methods of achieving its goal
- Implementation: Where the plan is actually put into action, following the steps of the System Development Life Cycle
- Close-Out or termination: where the plan is finished and the project is terminated.
Together, these steps that a project goes through in its lifetime is called the Project Life Cycle.
A project is really just a problem solving exercise with more than one person involved with limited resources and time. Projects are usually also characterised by their large size, complexity and higher cost. Still, you will notice many similarities between project management and problem solving.
Scope
Every project is constrained (limited) by its scope (what the project is trying to accomplish), time allocation and cost allocation. (Called the 'triple constraint'.) These constraints must always be in the project manager's mind as the project is designed.
Examples of projects are: changing existing information systems; new system; implementing a new tool; or producing new information (information that was not available by any method in the past.)
Examples:
- Adding the capacity to handle GST or Superannuation contributions to a payroll/accounting package
- Expanding a website to enable "shopping trolleys" and online ordering
- Replacing a manual inventory system with a computerised system
- Speeding up the process of ordering goods to stay competitive with other companies.
A project goes through stages, from Concept to Close-Out, only proceeding if the previous stage has been reviewed and judged to have finished satisfactorily. If any stage fails, the project may be redefined or abandoned altogether. There's no point trying to finish a race after discovering your horse is dead.
Why use project management techniques rather than making it up as you go along?
- less confusion
- less wasted time
- fewer false starts and "back to the drawing board" scenes
- better control of resources (money, equipment and staff)
- better customer relations
- shorter development times
- lower costs
- higher quality and better reliability
- higher profit
- improved productivity
- higher staff morale
Project Managers
The leader of a project is the Project Manager ("PM" to save space). He or she needs good technical skills. A manager who does not have the first idea of the nature of the task will not be able to make sensible decisions about its design or management. e.g. if a project involved programming a new database and the PM didn't know a database from a hole in the ground, how will he be able to decide how long a particular module should take to complete, or how many people to allocate to it? A PM need not be a world leader in the field (that's what the specialist staff are for) but he/she should know enough to be able to know make sense of what they're doing.
A PM also needs good communication skills to ensure the team members clearly know what they are doing. He or she needs good administrative and organisational skills to avoid confusion, waste and errors. A good PM has excellent leadership skills to motivate, guide and keep the team on target and working effectively and efficiently.
The role of the PM is to plan, organise and monitor the project from start to finish so it finishes on time, within budget, and actually solves the problem it aimed to solve in the first place.
Size does matter
Smaller changes to information systems can be handled less rigidly than larger, more expensive changes.
A smaller change may be successfully carried out without the SDLC... it may only need these simplified steps:
- Preparation: check the current equipment for compatibility with new equipment; inform people who will be affected by the change; plan when the change will occur; have 'Plan B' ready in case things get messed up (e.g. can you reverse the change? Do you have data backed up?)
- Execution: make the change and thoroughly test it to find faults or weaknesses.
- Follow-up: evaluate whether the change has succeeded; monitor the system to find and fix unforeseen problems arising from the change
A larger change should be handled as a project and use the System Development Life Cycle (SDLC) to guide people through the steps that must be carried out to finish the project successfully. When you are responsible for spending thousands or millions of dollars, your boss or shareholders will not be happy with a rough idea scribbled on the back of an envelope. They will want some guarantee that:
- there actually is a problem
- it is worth fixing
- the best possible solution has been found
- the financial costs, time, staff and resources will be needed to solve the problem
- if the project is allowed to proceed, that there is a fully detailed design before work begins
- the new or changed system is fully tested to ensure it works properly
- that the implementation of the new system is smooth and minimally disruptive
- that the new system is evaluated once it's working to ensure it actually has solved the original problem
The typical stages of the SDLC ensure these concerns are addressed. You'll hopefully notice that these stages are quite similar to the problem solving steps.
The stages of the Project Life Cycle |
|||||
Project |
Successful projects are well designed. As this article says, "Rather than rushing into development, [the project managers] spent some 55% of the project's time in the analysis and design stages and just 34% of its time in actual development... Spending so much time on design (industry figures suggest an average of 35%) paid off." |
||||
Project |
It is not possible yet to tightly specify what will happen when the project is implemented, but a broad plan can be sketched out. It should include: A revised look at the scope of the project (it might have been adjusted after the preliminary report was considered by management. Set Project standards (e.g. file naming schemes, variable-naming schemes, documentation, reporting, testing and validation techniques). If you are working on a problem alone, you can be more sure of consistency in its solution. You will probably use a single style for naming files, variables, doing indexing, using icons etc. If a team is working on the same task, however, it is critical that everyone understands and uses the same styles to avoid mass confusion and inconsistency. Imagine what an instruction manual will look like if every chapter was written by different people and each person used their own section numbering scheme (1,2,2a... i,ii,iii... 1.1,1.2,1.2.1 etc), their own fonts, their own icons and indexing style. The end result would be hopelessly confusing for the poor reader. More serious problems could arise, for example, if one programmer used explicit variable declaration but another didn't and they ended up working on each other's code: the resulting code could be riddled with obscure bugs. Set up a meeting schedule Meetings, Dog bless 'em, are unavoidable when working in teams. They are the best way to ensure the team is working as one. But, you probably don't want every member of a 200-strong team all meeting at once every Monday morning whether they need to or not. Meetings should be restricted to those who need to be there, and have definite agendas and targets. If the programming group need to meet over a planning issue, do the construction crew need to sit through it? A meeting schedule might get different teams meeting with different frequencies over time: the documentation team might not meet at all until well into the project, whereas the design team may meet long and often at the start of the project and only rarely, if at all, afterwards. Devise a rough project timeline and allocate resources While it's still too early to predict precisely how long the project will take, you can at least estimate ranges of time you expect each main stage will take (from the best case scenario to the worst cast scenario.) The most common tools to help with creating a timeline are the Gantt chart and the PERT chart. Using PERT, CPM (Critical Path Management) and/or Gantt charts to schedule people, equipment and resources will help avoid conflicts, and minimal times where things get too hectic if it can be avoided. Hire people when they're needed, not a week before so they're sitting around getting paid for twiddling their thumbs. Make sure trucks, test gear, storage space, specialist staff are free when they're needed. Do a task analysis This is a vital one. Here is where the Project Manager lists every task that needs to be done to finish the project. e.g. to build a factory, you would: clear the site; put up a fence; survey the land; put up temporary offices and buildings; dig foundations; lay cement; put up the frame; put up the walls; put on the roof; put in doors; put in windows; fit the electrics and plumbing; decorate the internals; landscape the environs; lay paths. If anything is left out of the task analysis, the results could be terrible: imagine finishing the internal decorations before remembering that no electric cables have been installed. |
||||
Project
|
The work is actually done to achieve the goal, following
the steps of the System
Development Life Cycle
|
||||
Project
|
The project is evaluated and terminated
|
||||
Now...
Because you've been especially good and haven't fidgetted
or cried, here's a little bit of fun: real-life reports of
mad project managers in action:
1. As of tomorrow, employees will only be able to access the building
using individual security cards. Pictures will be taken next Wednesday
and employees will receive their cards in two weeks.
2. What I need is a list of specific unknown problems we will encounter.
3. E-mail is not to be used to pass on information or data. It should
be used only for company business.
4. This project is so important; we can't let things that are more important
interfere with it.
5. Doing it right is no excuse for not meeting the schedule. No one will
believe you solved this problem in one day! We've been working on it for
months. Now, go act busy for a few weeks and I'll let you know when it's
time to tell them.
6. My Boss spent the entire weekend retyping a 25-page proposal that only
needed corrections. She claims the disk I gave her was damaged and she
couldn't edit it. The disk I gave her was write-protected.
7. Quote from the Boss: "Teamwork is a lot of people doing what I
say."
8. We know that communication is a problem, but the company is not going
to discuss it with the employees.
9. We recently received a memo from senior management saying: "This
is to inform you that a memo will be issued today regarding the subject
mentioned above."
10. One day my Boss asked me to submit a status report to him concerning
a project I was working on. I asked him if tomorrow would be soon enough.He
said, "If I wanted it tomorrow, I would have waited until tomorrow
to ask for it!"
11. As director of communications, I was asked to prepare a memo reviewing
our company's training programs and materials. In the body of the memo
one of the sentences I mentioned the "pedagogical approach"
used by one of the training manuals.
The day after I routed the memo to the executive committee, I was called
into the HR [Human Resources] Director's office, and told that the executive
vice president wouldn't stand for "perverts" working in her
company. Finally, he showed me her copy of the memo, with her demand that
I be fired - and the word "pedagogical" circled in red.
The HR manager was fairly reasonable, and once he looked the word up in
his dictionary and made a copy of the definition to send back to her,
he told me not to worry. He would take care of it.
Two days later, a memo to the entire staff came out directing us that
no words which could not be found in the local Sunday newspaper could
be used in company memos.
A month later, I resigned. In accordance with company policy, I created
my resignation memo by pasting words together from the Sunday paper.
Project Management in the news
Top Reasons Why Projects Fail
(from http://blogs.zdnet.com/projectfailures/?p=988)
A research paper Early Warning Signs of IT Project Failure: The Dominant Dozen, sheds light on the underlying causes behind many failures. The paper provides a framework for examining early-stage IT projects to identify and prevent downstream problems.
Here are the top people-related risks:
And the most important process-related risks:
- Lack of top management support
- Weak project manager
- No stakeholder involvement and/or participation
- Weak commitment of project team
- Team members lack requisite knowledge and/or skills
- Subject matter experts are over-schedule
Note that technology failures aren’t included anywhere in the list. As the authors say:
- Lack of documented requirements and/or success criteria
- No change control process (change management)
- Ineffective schedule planning and/or management
- Communication breakdown among stakeholders
- Resources assigned to a higher priority project
- No business case for the project
IT projects almost never fail because of technical causes, despite the fact that people and process problems may manifest technically…. Technical risks cannot be eliminated, but they can be managed.