Anticlue

Team Work in IS

In IS, you need to have a good working team. There isn’t really any other way to work. If you have an organization that is rife with discord, you don’t have a way to execute. I honestly know that with a good team, we can do anything together.

I’ve been blessed to work with a good team. I’ve had directors and managers in the past that really understood and appreciated the value of teamwork. It was an organizational goal, it was understood. You help when asked. Heck, you even offered to help, when not asked if someone looked like they needed help. It was great.

I’ve been able to work with desktop analysts, network specialist, server administrators, programmers, applications specialist, and even system analysts who understood the value of team work. My teammates helped me out, and I was able to help them out. It was a great feeling.

We were able to execute and get things accomplished. Individuals would discuss ideas openly, and debate the advantages and disadvantages.

The one failing at this time was that we didn’t extend the sense of team to the user community.

A Lesson Learned is that you need a team. A team is always better than an individual. Don’t destroy the team, and keep the team intaked.

Checklist of Charter Components

The following is the list of components that should be included in a charter document. However, depending on project size and complexity, some of the components may be excluded while some unique sections can be added. The listing of components does not assume any set sequence to create the documentation. Each project may require different emphasis for different components, ie for one project the project organization may be the first aspect that should be documented, for another project it may be the milestone timeline. However, the executive summary should usually be the last section created.

• Executive Summary
• Project Goals and Objectives
• Revised Scope and Requirements
  o should also include the current and ‘to be’ state
  
• Project Team
  o Identify the project organization, including governance, reporting, and escalation points
  o Define the project roles and responsibilities
  
• Implementation Strategy
  o Timeline – Include at a minimum a milestone timeline, but may also be a project plan to the known level of detail. Should also include a resource estimate for both IT and user.
  o Contingency Planning – describe what the impact on the project would be if the proposed live date is not met
  o Deliverables – identify the known deliverables for the project (should be referenced in timeline)
  o Testing approach – at a high level, describe the testing approach that will be utilized
  o Training approach – at a high level, describe the training approach that will be utilized
  o Cutover – document the known assumptions, constraints and approach for production cutover, including any contingency planning that will be needed
  
• Communication Plan
  o Describe how the project team will be kept informed. Describe how IT and user management will be kept informed.
  
• Critical Success Factors
  o Identify the major risks to the project and how these risks should be mitigated
  o Include any revised assumptions and constraints on the project, especially if they are different from Phase 1
  
• Issues list
  o Document any known issues. This should be the initial list that will be updated throughout the course of the project.
  

Acceptance Testing

Oh its a nice little word, but my is it a sigh of relief when completed.

Why the sigh of relief? Nerves? Not at all. For those involved directly, many long, hard work weeks, months are now turn into even harder, longer work weeks. Getting the final test cases validated is a difficult and time-consuming task. There are plenty of obstacles with the process.

But when you are done, you have the knowledge that all that is left is the live event. Issues will arise, but unit testing in most cases can resolve those issues. The obstacles jumps after acceptance testing are clearly defined with issues necessary for live, and post-live.

This is a milestone surely to be celebrated it is a golden event. The cumulation of a great team effort, because one never makes it to acceptance testing alone. The requirements have been met and we are moving forward, we are in acceptance state.

So as the time comes and passes remember the journey and the team the journey has created.

Pre-Charter

I will soon be in the wonderful place of bringing another group through a chartering process. So before I begin this trek, let’s discuss what items should be in place before chartering begins. I’m discussing chartering a project right before implementation. At this point in time, there already has been the conceptual phase and the building/acquisition phase is completed. So what elements do we need in place before we can really start this endeavor?

First, a business case should be in place. This will have the high level scope and requirements. The proposed budget, assumptions and constraints, and resources needed.

Next, since you have acquired a system, a contract is necessary. A good contract leads to a good implementation. The contract will clearly state the statement of work, and deliverables. It will also include a highlevel timeline for implementation with timeframes. If you are good at negotiating, then also include payment after key deliverables.

So in summary items that need to be inplace before implementation contracting.
· Business Case
· Budget
· Contract
· Scope and Requirements
· High Level Assumption and Constraints (including any expected timeframes)
· High Level Resource statement (Stakeholders, departments affected)

Issues Management

Issues Management on a large project is time consuming. On a project with a virtual team it is demanding, on a project with several virtual teams one really needs to have a web-based solution. Sometimes projects are implementation based others are build/construction based. I think there are different solutions available for both, but one that I have come across and happen to like is Eventum.

Why do I like Eventum? Well a couple of reasons, first it is very easy to use. With the pilot group consisting of the exceptionately computer literate to the "how do I use my mouse?", everyone was able to pick up Eventum with little to no training.

The second reason is that as soon as one logs into the product, there are analytics with where the project currently stands. Everyone can see who is overwhelmed, and what team needs to work down the issues.

Another reason is that one can have several teams designated for a certain project. Also one can have several releases for staged implementations.

There is also the history of how an issue was assigned and routed. Comments can be placed within the issue, and also documents of the problem at hand.

There are canned reports that are delivered with the system, and one can export issues to excel.

Now I know that with Eventum, it is not OOP. But honestly since I wasn't building it, that really wasn't a concern of mine. I also realize that with Eventum, others can change the notes. However, if you are that paranoid, maybe counseling is needed. Also Eventum is open-source, the install is a download away.

Individuals may have concerns about open-source software. There are many viewpoints on open source. Some individuals believe Open Source is the greatest thing on this planet. Others are cautious and risk-adverse of the open source solution. My concern with Open Source solutions derives from the need to be able to support it. Sometimes having someone to call or look to helps make a business case. I haven't found that party with Eventum yet.

When I went looking for an issue system, I was searching for a quick, easy to use, system implementation based solution with good analytics. Cost needed to be in the below $5000. Now we are looking at using a web-based issue system, but I'd like to offer up all solutions available. I know JIRA is a good system, but are there any others?