Little River Software
Home -> Articles -> Project Management
Defining The System Scope

Project Planning

Costing & Resourcing Planning


Every project or system comes with a budget, we need to create the system and get it up and running on time and inside the budget. Other areas of expenditure, such as hardware or marketing, must be also considered. The process of selecting suitable hardware/network infrastructure/marketing is very similar to the process of selecting software (or for that matter your new shirt/car/tie/house/bike). You review the requirements (no matter how simple or complex), and the budget (no matter how tight) and select a good fit. Controlling the other costs is also hopefully easier, than controlling people costs, as they are usually more easily quantifiable. For the purposes of this document however keeping the focus on people/development is sufficient to describe the project management / implementation process.

In a systems development project the two main areas of expense are usually Hardware and People. Hardware: because new systems sometimes need new hardware, and hardware can be costly. People: because people will write the system, test the system, give training, be trained, use the system.

People costs include the software developer (after all your programming might be done in-house) To determine people costs we need to start with a clear understanding of:

  • How many people?
  • What skills do they need? (and later related to this how much they cost per hour/month).
  • How long do we need them for? Permanently, the duration of the project, etc.
  • Where do we find them? New employees may incur recruitment fees, old employees may need training, developers from a contracting house come with a markup while developers employed full time have pension and other additional costs (and you carry on paying them after the project is over).

Depending on the size of the project you will need some or all of these people:

  • Project Sponsor
    • Sometimes the Project Sponsor is called the Project Owner. A separate Project Sponsor and Project Owner could be defined.
    • Arguably the most important person for any sizable project, because the responsibility for the project as a whole starts here, and ends here (or at least it should). The Project Sponsor is responsible for driving the project inside the client company. The Project Sponsor must have sufficient authority in the clients organisation to be in a position to compel activity in the organisation (should the unfortunate need arise).
    • If the project spans multiple departments, the Project Sponsor should have authority over all departments.
    • Without this mediator, inter department priority conflicts are very hard to resolve.
    • The Project Sponsor is often hard to find as persons that high in most organisations usually do not have sufficient time available to take a meaningful role in a project.
    • The Project Sponsor needs to "sell" the system to the internal user at all levels, and to acquire their commitment or buy-in for the effort that will be required later. Preferably, this "selling" of the system will not be a "hard-sell", as this starts to raise the possibility of "buyers-remorse" ocurring at a later date.
    • The Project Sponsor also needs to have sufficient sensitivity towards juniors to avoid making the juniors resentful. As their resentment will be re-directed towards the new system.
    • The Project Sponsor would be involved in choosing at least the internal Project Manager, as they will work closely for the rest of the project. If the Project Sponsor has too little time, the Project Manager will often act as a proxy for the Project Sponsor, this can work well, but sometimes Department Heads will not accept direction from a Project Manager. It all depends on the levels of complexity and nuance in the clients political/organisational hierarchy.
  • Internal Project Manager
    • A good Project Manager is key to the success of the project. In smaller projects, the Project Manager may be wearing other hats too, for example co-developer. This duplication of duties should be avoided in all but the smallest project as it reduces the focus on project management, and lack of project management is definitely a leading cause of project difficulties.
    • Responsible for managing the Project from an internal perspective.
    • Makes sure the client organisation does its share during the project.
    • Liaison between Project Sponsor and other teams.
    • Liaison between Internal Organisation and external providers.
    • Ensure that (already paid for) internal resources are used ahead of (as yet unpaid) external resources. Just be very sure that you are using resources because they are right-for-the-job rather than because-they-are-there.
    • Usually responsible for keeping to the budget although in very big projects, a project accountant may be used.
    • Responsible for ensuring that the project meets expectations and deadlines.
    • This position requires an individual who can see both sides in an discussion, as the Project Manager will often be required to mediate between developers and users. A good Project Manager needs to be able to tell either the developers or the users "no" when it is appropriate. And for that matter be able to accurately judge what constitutes appropriate.
    • The Project Manager will also be responsible for preventing scope creep (discussed later).
  • External Project Manager
    • In the case of external development, this manager would monitor the developers and liaise with the internal Project Manager. Unfortunately in the case of external development companies, this person is sometimes also the sales person, or the account manager, and not all sales / account manager persons have the required Project Management skills. In addition, simultaneously assuming the duties of a sales / account manager and a Project Manager hat can cause conflicting priorities.
  • Business Analyst(s)
    • Interviews users, studies the business, identifies required functionality, and sees that that functionality gets into the scope / specification.
    • The business analyst should be the one who identifies procedures and practices that are still required, that are missing but are required, and those that are no longer required. For some reason this often does not happen. At this point the project manager needs to get the Business Analyst back on track.
    • Despite the importance of a good business analyst, many organisations seem to move people into a business analyst role when they cant find another place for them. Do not immediately assume that the business analyst has sucessfully gathered all the requred information, or that that information is correct. Like any other part of the requirement specifiction, the output from the business analyst should be fed back to all the interested parties for confirmation.
    • Watch the relationship or the dynamics of the interactions between the business analyst and the people they interview. If the person being interviewed develops almost any negative feelings toward the business analyst, they often get reticent about the little, but critically important, details. Highly qualified, but young, business analysts may have a harder time getting the right info out of highly experienced, older and less well paid staff. Warning attitudes from the person being interviewed include:
      • This analyst knows nothing.
      • This analyst knows nothing about my business.
      • Stop bugging me I am too important to waste time like this.
      • If you are so smart, why dont you figure it out.
      • I know more than you, but you get paid more.
  • Developer(s)
    • Usually the people who actually create something are quite near the bottom of the organisational tree.
    • Try to avoid simply passing a spec to the developer and leaving them alone. Try to involve them in earlier discussions, and keep them involved as the project progresses.
    • At the same time try not to tie up the developers in constant meetings when what they should really be doing is writing code (or building rockets). Finding a balance between keeping them informed about unfolding events, and wasting their time is tricky but important.
  • End Users (internal)
    • Usually the people who actually have to use the system are also quite near the bottom of the tree.
    • It is critical to the success of a system that the end users, are happy. Start their involvement right at the beginning, keep them informed and involved, train them well. In short look after them.
    • Let the developers talk to the staff. Assuming your developers are not of the leave-me-alone-to-write-code variety, you may find that as they share a feeling of overworked and underpaid with the staff, they get on supprisingly well. If they develop a reasonable relationship, they will quite possibly uncover some of the missed details (and there are always a few).
  • Trainer
    • Especially on big projects, it is common to train specialist trainers who then train the rest of the user base. This is often done because developers tend to talk over the heads of end users, and because trainers are often cheaper than developers.
  • Project Secretary
    • Some projects generate a lot of paperwork.
    • All projects generate a lot of project information and someone should look after it.
      • System Specifications
      • Requirement Documents
      • Requests for tender
      • Tenders or Quotes
      • Contact Details
      • Mail Lists

Avoid stereotyping the people involved in the project (probably good advice for life in general). For example some programmers like to work in the basement, alone and frantically typing complex code, others like to interact personally with their users. Some older users will resist the change to a new system, others will welcome it. If you apply stereotypes to the people you are dealing with (and project management is largely a matter of people management) you will miss clues about the people and their reaction to what they have to do, and therefore how well they will do it.

Good communication between these people is vital. In the more cumbersome project/organisation many of these people will meet, too frequently, in a steering committee meeting. Sufficiently good communication between these parties can reduce the need for such meetings. Excessive meetings can eat up productive time, and therefore budgets in a flash. Being asked to put meetings in the project plan is a reasonable early warning sign. Reducing meetings in this type of organisation is not easy, if you have some ideas on how to achieve this, please let us know, we can schedule a meeting to discuss it.

Defining The System Scope

Project Planning