Running a Project on a Shoestring Budget

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

If you’re working in a large corporation with a very professional PMO already in place and a handsome budget set for the project you’ve just acquired, then this article is probably not for you.

Budget management is always important, but it’s highly likely that the amenities you need to manage your project with the high-paying customer that has been lined up are already built into the overhead of the project. The flights to the customer site are built in by Sales during the negotiation process, as are some additional equipment that may be needed specific to your project and implementation.

However, if that is not the type of project you’re running, then please read on as you might find something interesting or helpful from this information. I’ve been working mostly remotely as an IT project manager for the past 3+ years. Sometimes that has involved running large multi-million dollar projects for deep-pocketed clients meaning the little things and extras on a project definitely aren’t an issue. No concerns with cutting back because certain things are expected and are built in to the overall price of the project.

On the flipside, if you’re an independent consultant – as I am – and you have a mix of customers, then you’re likely to have a few clients that do not have deep pockets. These clients watch every dime they spend and that means of course that everything you do can and will be subject to their scrutiny. It also means that you have to watch how you do business carefully because you’ve likely not been able to price the project with a comfortable profit margin. It’s more likely that your margin is small and if something goes wrong causing extra work – and it’s your fault – you could be doing much of the work for free!

Here are some specific things that I do to reduce costs, keep things greener in terms of resource usage, etc. and keep the customer’s expectations steady in terms of on-going project costs:

• Bill the client a fixed price every two weeks or every month. This is basically like a retainer and if I’m doing this, I bill the work up front. It’s too risky in this economic climate to bill after the fact. Only do that if you really want (or need) this particular customer and they won’t budge at all on the upfront billing issue. Most will budge or meet you halfway letting you bill at the beginning of a two-week period and then pay you one week into it.
• Use video conferencing and teleconferencing whenever possible. This way you can avoid costly travel for the project and for your client. You can get video conferencing setups free at places like DimDim (www.dimdim.com) and you can get free conference calls at Freeconferencecall.com.
• Use free over-the-web fax services. Faxzero (www.faxzero.com) allows you to send faxes for free and Faxdigits (www.faxdigits.com) gives you a number to receive faxes with – they then come to you as a pdf file and you retrieve them online.
• Use a free pdf document converter. There are an increasing number of free pdf converters available now. It use to be that you had to have an expensive version of Adobe Acrobat to convert files to pdf format. Now you can download software like PrimoPDF (www.primopdf.com) and CutePDF (www.cutepdf.com), among others. I’ve tried several of these and the quality so far has been good on every one that I’ve tried.

Summary

There are a lot of options available these days to make the small vendor or independent consultant look bigger and many of them are free. The key is to start looking now, test out your different options and chose the best one. You definitely want to look professional and be ready when the need is there, so don’t procrastinate.

The Importance of Testing

Any IT solution that is implemented without the proper amount of testing performed throughout the project is a definite recipe for disaster. Testing is an ongoing process – both formally and informally. It happens in development, it happens in the actual testing phase, it happens just prior to deployment and it happens post-deployment.

In his book “Project Management Nation”, Jason Charvat discusses the importance of testing throughout an engagement and identifies the different types of testing that we usually carry out in both informal and formal processes. By sharing this information here, I am not fully endorsing it, however I do find it interesting and likely beneficial to our readers.

The Importance of Testing

Without a well-thought testing effort, the project will undoubtedly fail overall and will impact the entire operational performance of the solution. With a poorly tested solution, the support and maintenance cost will escalate exponentially, and the reliability of the solution will be poor. Therefore, project managers need to realize that the testing effort is a necessity, not merely as an ad hoc task that is the last hurdle before deployment.

The project manager should pay specific attention to developing a complete testing plan and schedule. At this stage, the project manager should have realized that this effort would have to be accommodated within the project budget, as many of the testing resources will be designing, testing, and validating the solution throughout the entire project life cycle—and this consumes work-hours and resources. The testing effort begins at the initial project phase (i.e., preparing test plans) and continues throughout until the closure phase.

Testing Criteria

It is essential to conduct tests under realistic conditions. Often times the testers on a project deliberately go out to destroy the solution during the testing phase in order to do a proper test. Some sensible ground rules for acceptance testing are necessary and need to be established before any testing commences. Typically, some of these rules should include the following:

• Using real data and real operators.
• Test the solution as the developers build it. This way, errors can be corrected immediately.
• Involve project members who understand design and user specifications.
• Determine what is included within the test and what is not.
• Involve users of the project who know how the system will be used.
• Test to see that interfacing the new solution to the current infrastructure has no unexpected consequences.
• Allow time for repetition of those unsatisfactory test results in the project schedule.

Types of Testing

There are many different types of testing that can take place on an IT project, and the project manager must verify exactly which tests will be required and when. Below is a list of the most common types of testing that usually encountered on a project:

The IT Auditor’s Role in the Software Development Process

In further examining the IT Auditor’s role in the IT project environment, I’d like to look at how the book “Information Technology Control and Audit” discusses the IT Auditor’s role in the overall software development process.

Software Development Process

A formal systems development process provides an environment that is conducive to successful systems development. This includes: (1) an information systems strategy that guides developers in building systems that are consistent with the organization’s technical and operational goals, (2) standards that guide in the selection of hardware, software, and developing new systems, (3) policies and procedures that support the organization’s goals and objectives, and (4) project management that ensures projects are completed on time and within budget. Auditors can assist organizations by reviewing the systems development process to ensure that developed systems comply with the organization’s strategy and standards.

Software Development Phases

The systems development process can be broken down into four phases:

• Planning
• Development
• Implementation
• Maintenance

The planning phase sets the stage for the success of the development effort. If not done properly, the budget and schedule may not be sufficient, the problem may not be adequately defined, the final project may not solve the business problem, and the right people may not be involved. The planning phase of systems development includes the following activities:

• Needs analysis: a study to determine whether a new system should be developed
• Current system review: a study of the current system to identify existing processes and procedures that will continue in the new system
• Conceptual design: preparation of the proposed system flow and other information illustrating how the new system will operate
• Equipment requirements: hardware configuration needed to process and use the new systems (e.g., processing speed, storage space, and transmission media)
• Cost/bene?t analysis: detailed financial analysis of the cost to develop and operate the new system, the savings or additional expense, and the return on investment
• Project team formation: identify people from programming, user departments, and support departments to develop and implement the new system
• Project plan: an overall project plan with defined tasks and deliverables to monitor actual results and ensure successful progress

Auditing can be involved in the planning process to develop an understanding of the proposed system, make sure time is built into the schedule to adequately define controls, and verify that all the right people are involved.

There is a definite correlation between a well-managed systems development process and a successful system. The use of a proven system development methodology increases the probability that the system’s internal controls will be effective and reliable. As discussed under the traditional development approach, systems development includes the following phases:

• Analysis: Define what is required of the new system.
• Design: Define how to build the new system to satisfy the requirements.
• Construction: Build the new system using the design information.
• Testing: Verify that the completed system meets the users’ needs and functions without fault.
• Implementation: Deliver the completed system to the end users; obtain satisfactory feedback.
• Maintenance: Modify the system as needed to correct problems or meet changing needs.

Auditing can review the development process to ensure the software is designed with user requirements documented, that management approves the design, and that the application is tested before implementation. An additional focus is ensuring that the end user is able to use the system based on a combination of skills and supporting documentation.

Detailing the Project Management Audit Process

Diving a little deeper PM audit process as described in the book “Information Technology Control and Audit”, we will look at the audit planning, the actual PM process review, the act of working with the PM and team to identify risk, and the communications necessary to ensure that the audit process is as successful as possible.

Audit Plan

The audit plan will detail the objectives and the steps to fulfill the audit objectives. As in any audit, a project management audit will begin with a preliminary analysis of the control environment by reviewing existing standards and procedures. During the audit, these standards and procedures should be assessed for completeness and operational efficiency. The preliminary survey should identify the organization’s strategy and the responsibilities for managing and controlling development.

Project Management Process Review

A project management process review would assess the adequacy of the control environment for managing projects. The review points listed represent checkpoints in the project management process. Auditors can use these checkpoints to determine both the status of the project’s internal control system and the status of the development project itself. These reviews eliminate the necessity of devoting large amounts of audit resources to the development effort. As long as the development process is well controlled, the need for audit involvement is minimized.

Project Management

Auditors may assist the project manager in identifying project risks and evaluating plans to mitigate and manage risks (e.g., training, devoted resources, management support, and end-user commitment). Auditing can provide management with an independent review of project deliverables (e.g., project charter, task list, schedule, budget). Auditing may also review the project task list and budget to verify that all project tasks are defined and all milestones have a deliverable.

During the planning phase the auditor can facilitate communication between functions and raise issues that may impact the quality or timeliness of the project. In a development project, resources from various departments need to come together to implement an automated process that may affect multiple user functions. Because of various audit projects, auditors develop an overall knowledge of the organization and establish relationships in multiple departments. These relationships are helpful in a development project for making sure information is flowing between the development team and other functionaries. Consider the following groups:

• Primary users
• Secondary users
• Vendors and consultants
• Programmers and analysts
• Database administrators
• Testing teams
• Computer operations
• Interfacing systems
• Implementation team
• Production support (i.e., maintenance programmers)

Verify that adequate resources are assigned responsibility for tasks and have the time to complete assignments. This includes development, computer operations, user, and support functions (e.g., help desk).

Communication

The first area to communicate is the auditor’s role in the systems development project. It is very important to make sure that the management and development teams’ expectations of the auditor’s role are understood and communicated to all participants. In order to influence the systems development effort, the auditor must develop an open line of communication with both management and users. If a good relationship between these groups does not exist, information might be withheld from the auditor. This type of situation could prevent the auditor from doing the best job possible. In addition, the auditor must develop a good working relationship with the manager, the analysts, and the programmers. Although the auditor should cultivate good working relationships with all groups that have design responsibilities, he or she must remain independent.

Recommendations

Throughout the development project, the auditor will be making control recommendations. Depending on the organization’s culture, these recommendations may need to be handled informally by reviewing designs with the project team or formally by presenting recommendations to the steering committee. In either case, the auditor must always consider the value of the control recommendation versus the cost of implementing the control. Also, recommendations should be speci?c, identifying the problem and not the symptom. This allows the proper controls to be implemented and tested.

Recommendations are often rejected because of a time and cost factor. Managers may sometimes feel that implementing an auditor’s recommendations will put them behind schedule. The auditor must convince management that if the recommendations are not implemented, more time and money will be spent in the long run. Informing management of the cost of implementing a control now rather than shutting down the system later to repair it or leaving possible exposures open will help convince management of the need to spend time and money now.

Ten Guidelines for Managing Passwords in the Enterprise

As a follow-up to my article entitled “The Most Serious Data Threat May be Sitting Next to You,” Mark Sanford from Click Studios sent me a link to their article on “10 Guidelines for Managing Passwords in the Enterprise.” Since data security and data integrity is a critical issue on any enterprise IT project that involves significant data – and they all do – this is extremely timely and appropriate.

Mark and Click Studios have graciously allowed for their article to be provided to the readers of PM Tips. I strongly urge you to also visit their site and the original article here.

10 Guidelines for Managing Passwords in the Enterprise

Today the world is totally dependent on information technology, and many corporations struggle to effectively manage and store passwords securely for their employees. Every other day you hear of large companies exposing customer account details to non-intended audiences, due mainly to poorly managed IT systems and processes. The confidentiality and integrity of sensitive data is paramount to the operations of any size business, and the following guidelines should be considered when choosing any type of electronic password management system (PMS).

1. Remove the need for employees to remember passwords, or even worse, write them down

A key cause of bad password management practices is many employees don’t have a system in which to records their passwords, resulting in them having to either remember them, or write them down and store them in an unsecure manner. The password management system (PMS) must provide adequate functionality, removing the need for employees to remember passwords.

2. Centralize the management of passwords

Centralization of an organization’s passwords is the first step in gaining control of the IT accounts used to operate their business, otherwise there is no visibility or governance of their usage.

3. Ensuring the integrity of sensitive data

To ensure the integrity of data stored in an electronic PMS, there are a few key things to consider:

• Passwords should be encrypted with 256bit AES encryption, and a unique Initialization Vector used for every install
• Users should authenticate against the PMS using their Microsoft Windows domain account credentials
• PMS must provide the option to use two-factor authentication for the user(s) who administer the system
• Sensitive code of the PMS should be obfuscated, to prevent reverse engineering by system or web administrators
• PMS must mitigated against system or database administrators granting themselves access to unauthorized data

4. Make the passwords easily accessible

Users must be able to get to the PMS from any location, must not rely on any client installs, and must give them quick and easy access to their passwords.

5. Must promote the use of strong passwords

The PMS must promote the use of strong passwords, of which the policy for password strength is set by the administrator(s) of the system. Visual representation of password strength must be available when entering passwords, or when reporting against, so the user is constantly reminded if a password’s strength is poor.

6. Must promote regular resetting of passwords

A key component of bad password management practices is not resetting passwords at regular intervals. The PMS must have one or more options for reminding users that passwords are about to expire.

7. Must be portable and recoverable

There is little use centralizing your organization passwords if you’re unable to get to them in case of a disaster. The PMS must provide the mechanism by which all passwords can be exported to a separate file, to be stored outside of existing IT systems – preferable with trusted security personnel.

8. Changes must be traceable and auditable

All large organizations require governance over access to IT systems, and its imperative the PMS must support traceability of all events within it, and must be easily reportable. This applies to standard usage by employees, or administration of the PMS.

9. Must be scalable

If you intend to implement an enterprise class PMS, its crucial the system can scale with your organization, otherwise your investment (time and money) may be wasted.

10. Must be simple to use

As with any IT system, acceptance by its audience is crucial to its success. Provide users with a poorly designed interface, and you will meet resistance at every step. To successfully employ a PMS and realize the benefits it can bring, the PMS must be very simple to use and provide the user community with sound help documentation if required.

(Click Studios – 18^th October 2009)