th=
e_company
Project Management
Project
Management Process & Training Manual
Document
Revisions
Revisions on this document should be recorded in the table below:
Ta=
ble Of
Contents
2.1.1 Control of the the_company team
2.1.3 Control of Third Parties<=
!--[if supportFields]>=
2.1.4 How to develop relationships<=
!--[if supportFields]>=
2.1.5 Compliance to the_company Standard
Operating Procedures
2.2 Senior Project Managers<=
!--[if supportFields]>=
2.3 Project Directors<=
!--[if supportFields]>=
2.3.1 Project Director as Line Manager<=
/span>
2.3.2 Project Director as Team Lead<=
!--[if supportFields]>=
2.3.3 Project Director as Agent of Upper
Management
2.3.4 Project Director and Accounts
Receivable
2.3.5 Project Director as Client Relati=
onship
Manager
3.3 Project Specifications<=
!--[if supportFields]>=
3.3.1 The Requirements Specifications
Document
3.3.2 Determining the version of your
specification document
3.4 Resources Planning and Project Time=
line
Development
3.4.1 Resources Planning<=
!--[if supportFields]>=
3.4.2 Project Timeline Development
3.4.3 Introduction to MS Project=
3.4.4 Introduction to MS Visio<=
!--[if supportFields]>=
3.5 The Development Phase<=
!--[if supportFields]>=
3.5.1 Ping your developers<=
!--[if supportFields]>=
3.5.2 Using CVS to keep track of the
development progress
3.5.3 Coordinating all departments invo=
lved<=
!--[if supportFields]>=
3.5.4 Working with clients<=
!--[if supportFields]>=
3.5.5 Organise and manage unit testing =
with
clients and third parties
3.6 Testing (UAT and Unit Testing)
3.6.1 The test plan phase<=
!--[if supportFields]>=
3.6.2 The testing phase<=
!--[if supportFields]>=
3.6.3 Prioritising your bugs<=
!--[if supportFields]>=
3.6.4 Coordinating with your clientR=
17;s
testers and third parties
3.6.5 Managing the UAT environment
3.6.7 Unit Testing<=
!--[if supportFields]>=
3.6.8 Internal Testing<=
!--[if supportFields]>=
3.7 Documentation, Training and Handove=
r
3.7.1 Documentation<=
!--[if supportFields]>=
3.8.1 Assigning a techie for the warran=
ty
period
3.8.2 Escalation Procedures<=
!--[if supportFields]>=
4.1 Weekly Progress Reports<=
!--[if supportFields]>=
4.2 One-to-one’s<=
!--[if supportFields]>=
4.3 Weekly Team Meetings<=
!--[if supportFields]>=
4.3.1 Meeting Structure<=
!--[if supportFields]>=
4.4 Meeting minutes (with clients and t=
hird
parties)
5 Project =
Risks<=
!--[if supportFields]>=
5.1 Risks from the_company<=
!--[if supportFields]>=
5.2 Risks from Clients<=
!--[if supportFields]>=
5.3 Risks from Third Parties<=
!--[if supportFields]>=
5.5.1 Risk identification<=
!--[if supportFields]>=
5.5.2 Develop strategies to handle/mana=
ge the
risk
5.5.3 Example Case Study<=
!--[if supportFields]>=
5.5.4 Be creative<=
!--[if supportFields]>=
6 Producti=
on
Issues and Post Mortems
6.1 What to do when there is a producti=
on
issue.
6.1.2 Support & Maintenance<=
span
style=3D'color:windowtext;display:none;mso-hide:screen;text-decoration:none;
text-underline:none'> <=
!--[if supportFields]>=
7 Billings=
<=
!--[if supportFields]>=
8 Manageme=
nt of
Clients and Third Parties
8.1.1 What To Do & What Not To Do
(Especially with new clients)
8.1.2 Tips & Things To Keep in Mind=
<=
!--[if supportFields]>=
10.3 Example of a Variations/Additions =
table<=
!--[if supportFields]>=
10.4 Handling Additions and Variations<=
/span><=
!--[if supportFields]>=
11.1 Correspondence<=
!--[if supportFields]>=
11.2 Other Documents<=
!--[if supportFields]>=
13 Syncing=
your
laptop for Offline Network and Email
13.1 Making the network available offli=
ne<=
!--[if supportFields]>=
13.2 How to access the the_company Intr=
anet
remotely
13.3 How to access to your email remote=
ly<=
!--[if supportFields]>=
13.3.1 Use pine as the email client
13.3.2 Use a MS Windows GUI email clien=
t
13.4 How to access files on Bacchus tha=
t were
not synced to work offline
13.5 How to setup dialup Internet acces=
s in Country2<=
!--[if supportFields]>=
13.6 How to retrieve voice mail when ro=
aming
in other country
13.6.2 Singtel GSM 1800<=
!--[if supportFields]>=
14 Appendi=
ces<=
!--[if supportFields]>=
14.1 Example of a good Requirements
Specification document
14.2 Example of a good UAT Test Plan<=
!--[if supportFields]>=
14.3 Example of a good Meeting Minutes<=
/span><=
!--[if supportFields]>=
14.4 Example of a good Weekly Progress =
Report
14.5 Example of a good Daily UAT Report=
14.6 Example of a good Post Mortem Repo=
rt
15 Credits=
<=
!--[if supportFields]>=
1 Intr= oduction
Welcome to the the_company Project Management team! This documen= t will provide you with all the standard guidelines that will allow you to underst= and the Project Manager culture in the_company.
This document will give you theoret= ical guide to doing a good project management job. However, as with all theories when applied to practice it will require your own creative thinking to make it useful and work for you. So t= he key to a better understanding is to actually do it, i.e. hands on training!
After reading this document, you sh= ould schedule sometime with the other the_company Project Managers to get a clea= rer picture of the “real world”.&n= bsp; Some key people to talk to are:
- XXX
- YYY
- ZZZ
2 Role= and Responsibilities
2.1 Pr= oject Manager
The the_company Project Manager is ultimately responsible for the delivery of projects on time, within budget;= up to the high quality that the_company is known for, and according to the standard operating procedures defined by the_company.
In short, the role of the the_compa= ny project manager is to control projects.
The act of controlling projects can= be broken down into four responsibilities:
- 2.1.1 =
Control
of the the_company team
A good portion of your time will be= spent managing the software developers, web designers, content developers, and infrastructure engineers on your project team.
2.1.1.1 The Project Manager as a Nanny
To some degree, you are like a nann= y. You should be protecting your team= from the client and third parties to the best of your ability. Control their env= ironment so that they can spend 100% of their time doing what they do best: architec= ting and building software solutions.
In the ideal case, you should be ar= ranging their transportation, setting up meetings for them, and taking minutes for = them at those meetings. In general, you want your developers to be relaxed, happ= y, and focused. Whatever you can= do to help get them into that state, the better.= Be creative. The happier your developers are, the more you will be a= ble to drive them and the more they will owe you when you need to ask them to w= ork over night.
2.1.1.2 The Project Manager as a Task Manager
But you are not just a soft and fri= endly nanny. You are also a hard-edged task master. You must make sure that your = team is working according to the timeline and within the quality standards defin= ed by the_company. In the end, t= he project manager (you) is the one who takes the heat if a project is late, n= ot the techies. It is up to you to hit your targets because it is your butt th= at is on the line.
Having your butt so exposed means t= hat you need to have strong and active lines of communication with your developers = so that you will be aware as soon as there is any project risk. The reason for this is that the on= ly way you can avoid getting slammed for delivery slippage is by giving early and accurate advanced notice of project risk.&= nbsp; If you give the client and your manager at the_company fair warning,= you can usually avoid getting in trouble for delivery slippage. This is because, the client and the_company have enough time to creatively work around the slippage.
2.1.1.3 Project Manager as an Overseer
You are also an overseer. You must make sure that your devel= opers are doing their job properly. This means that you must facilitate peer revi= ew, read and edit their documentation (after all, if you cannot understand the documentation, it is probably poorly written), and generally run spot check= s to make sure that things are as they are reported.
Speaking of reporting, you can choo= se to manage communication any way you’d like to, but it is recommended that you have your team submit the standard the_company developer progress repor= ts to you each week, and that you hold weekly meetings to chat about status and issues.
Certainly you will also be responsi= ble for submitting a weekly the_company progress report of your own for your manager and participating in project manager meetings. It is crucial that you give = the progress report draft to all members of your team and to the client’s project team before Thursday so that they can comment before it is due (clo= se of business Friday).
2.1.1.4 Project Manager as Team Member
Finally, because we are small compa= ny with limited resources, you will be responsible for coordinating with the rest of the the_company office. For example:
- You must make sure you understand all the legal issues in= your project.
- You must inform the marketing team about launches with en= ough time for them to prepare.
- You must provide the marketing team with client-approved = client success stories after projects are delivered.
- You must work with the original sales person on the proje= ct to come back in for post-sales work when the time is right.
- You must notify accounting when they should bill the clie= nt for work completed.
- You must coordinate the usage of shared resources like infrastructure team members, designers, content developers, legal specialists, laptops and the LCD projector with other project managers= .
2.1.2 = Control of the Client
Clients are lousy! They generally don’t know wh= at they want, do not understand the technology (and are often intimidated by i= t) and do not know what is possible or impossible, want to sneak as much by yo= u as they can so as to get more work done for the same cost, probably have poor communication skills with you, their own teams and third parties, have unre= alistic expectations, and have their own butts and reputation exposed in terms of t= he success or failure of the project you are running.
Nevertheless, the client is also ou= r best buddy. He is the expert of his business rules, the one who is paying us to grow the company and get you a promotion, the one with the ability to feed us additional follow-on project= s, and the one with the ability to give us great recommendations and client-ku= dos.
So the balancing act you must play = with the client is quite difficult and there are several things you will need to do well.
2.1.2.1 Managing the Functional Specifications
For one, you must manage the evolut= ion of the functional specifications. While you will only be required for managing your senior developers = in writing the initial drafting of the functional specs, once the specificatio= ns have been signed off, you will own them.&n= bsp;
As the owner of the functional specifications, you must make sure that the client does not sneak any requirements through without either paying for them or having the_company explicitly agree to absorb the cost of the “additional work”.
2.1.2.2 Communication Streams
You must also keep a constant strea= m of communication open with the client throughout the development process. Because most clients do not know w= hat they want and do not know what is possible, it is you duty to keep them informed with prototypes, screen shots, demos, workflow diagrams or whatever you can come up with. The client should not be surprised when he finally se= es the finished product and in order to assure that he is not surprised, you n= eed to manage him.
Certainly, some of this communicati= on will be facilitated by the use of standard the_company weekly progress reports a= nd project meetings, but it will be crucial that you follow up with more infor= mal chat sessions. Perhaps a dinn= er on the_company once every couple of weeks would lighten the mood and allow you to discuss = some of the more touchy issues. This is acceptable and encouraged.
2.1.2.3 Managing Mid-Development Activities
During development, there will also= be plenty of other things that you need to manage. Does the client have her own devel= opers, infrastructure team, designers, marketing people, sale people, audit people= , or QA people that need to be involved in the project? Do these people represent dependencies that must be solved if your developers are to do their work? If so, you need to manage them carefully. They may not only not care about your project but also might even hold a grudge against your project and seek to hamstring it subtly. Suppose they just don’t personally like the proj= ect sponsor and what to make him look bad.&nbs= p; You might be the unwitting pawn in the middle of a secret war at the client’s site.
2.1.2.4 Managing the Productionization Process
Certainly, there will be a lot of d= ependencies when it comes to moving development software into the staging, and the production, environments. The= re could be client-side SOPs that you must comply with in terms of forms that = need to be filled out when anything goes through testing or into production. You will need to find out what the= se processes are early and make sure you, or your project sponsor complies.
Further, you must manage the User Acceptance Testing (UAT) period. This means training the client’s tes= ting team on how to properly test the application and use the the_company Bug Tracker, as well as composing and managing the implementation of the test p= lan.
2.1.2.5 The Project Manager as Salesman
Finally, you need to perform the jo= b of salesperson. Today, most of the projects done by the_company have been done= for previous clients. In fact, ov= er 60% of our projects are repeat business. As project manager, it is your responsibility to make the client feel happy with the_company. They = should trust the_company and want to bring more work our way.
One way to help this is to run one2= one sessions with the client at critical points in your project. Let them give = you feedback as to the successes and failures o the project ad get that feedback back to the_company so that we can refine our PM process even further.
2.1.3 = Control of Third Parties
Third Parties are other vendors, pe= ople, projects, the_company-side players, or client-side departments that have effects upon your project but who are not necessarily directly involved.
Firstly, third parties have an exceptionally powerful ability to screw your timelines up and wrest project control from you. These parti= es often do not have the same goals or priorities as you. In fact, they may ha= ve contradictory goals, especially if they are competitive software firms at t= he same client site. yet, they often represent a key dependency that if not managed can lead to timeline slippages.&nb= sp; So, by managing third party vendors, you reduce your own risk exposure. Few people want open conflict, so with the right management, you can even control outright enemi= es and get them to do work for you.
Secondly, while we cannot officiall= y take on the responsibility of managing third parties, when done well, the client will be mightily impressed and thankful.&n= bsp; Thus, one way to manage your client is to help him manage “his” risks.
Finally, many third parties will no= t be enemies at all, but potential partners.&nb= sp; Managing them in a project allows us to build relationships for networking, easier knowledge transfer, and assures a mutual assistance for timeline constraints or deliverables that are dependencies. They also repre= sent potential sales or biz development opportunities.
There are of course risks involved = with taking on Third Party Relationship Management.
The biggest risk is that the client= will grow to assume that we have the responsibility for the vendors’ work = and will identify us as the primary point of contact. This is okay when things = are going well, but it is terrible when things go wrong. As you manage third parties, you must be sure to make our roles and responsibilities clear. We = are there to help smooth out the project so that “we” can deliver.<= /span>
Another risk is that you may spend = a lot of time with third party issues. However, this is probably worth it when you consider how much time would be spent if you do not manage he third party.<= /span>
A further risk is that your inexper= ience could lead to you being manipulated. Always remember that the third party h= as a different agenda from you. While it may be a synergistic relationship, keep your distance and don’t drop your guard.
Finally, clients may actually play = vendors against one another specifically to control the lines of communication, as = the vendors mistakenly believe the only trustworthy source of communication is = the client rather than the other vendor. While we don't believe in the long-term efficacy of this, this can be an issue.
For example, one of our early clien= ts at the_company actually forbade us to talk to the other 3rd party vendor about the project. They only wanted us to go through them. The official reason was for NDA agreement. But the actual reason (which became apparent later) was that the= 3rd party and the client were having trouble with each other from the past and = they did not want their bad relationship to spill over to us.
Clearly, the management of third pa= rties is the most difficult part of the project to control. The rule is to tread carefully and never, never let our guard down no matter how 'nice' some people might seem= to be.
Although every project is different= , there are general tools and tricks that we can use to deal with similar patterns = of problems.
Most importantly, we need to out ma= neuver the opposition. We need to co= ntrol and manipulate the ENTIRE PROJECT ENVIRONMENT in favor of eXtopia and our P= Ms and developers
Think more creatively about how to = manage third parties. As a company, = it is true that we are strong because of our PM processes. But our strength clear= ly has limitations. In fact, if = it has to come down to documentary evidence, it is likely an indication that the process may have "failed" and that the legal process has begun.
That is, by the time we get down to variations tables, and minutes, and functional specs clarifications, the cl= ient is probably fairly irate whether or not it is our fault or fair. It most likely means that we are g= oing to need to rectify this in some way by either absorbing the mistakes and ti= me or by passing back a discount to the fee.&= nbsp; This is what we do NOT want to do.
Before the Project Starts:
-
2.1.4 = How to develop relationships
2.1.4.1 Entertainment
A meal that the_company would reimb= urse is always a reasonable idea to grease the wheels. When dealing with 3rd party vendors, the first thing to do is to take out their PM. The second thing to do is to take = out their lead developer. You want to get them into a position where they consi= der you a friend.
2.1.4.2 When it's a 3rd party vendor, their primary concern is making money.
Think of ways that we can help their business and then try to also talk to them from a business development perspective. Partners are less likely to backstab each other. Even a firm t= hat does what we do is a potential partner. Play up the fact that we, too are small, and occasionally we have to bid for a project that is larger than us= ... and although we can do a lot on our own sometimes we have to turn work away. That we are always looking for reliable outsourcing partners (which is absolutely true). Then the psychological subtlety is to let them realize on= their own that If they prove themselves by working well with you on this project,= we will be more likely to pass on work to them because we like them. MAKE them LOOK GOOD.
2.1.4.3 Look for the right person within the 3rd party vendor relationship who can help = you.
There are different people in the 3= rd party and while some may be closed and tight lipped, others may be more open.
2.1.4.4 Example Case Study
Let's say the boss in the 3rd party= is paranoid so they might be a hard target to take out. But the 3rd party developer on the project might be someone who would appreciate you talking = to them (and in fact they might have their own ulterior motives like finding o= ut whether the_company is hiring!) and would have looser lips than their boss.= In some cases, the seemingly "less important" developer (less import= ant in terms of not having direct client contact) may actually be just the right friend to have because they may have a much more realistic point of view of= how the project is really going than their boss does.
- Open and frequent. The advanc= ed PM knows how to use communication and relationships correctly and has an intuition for how and when to give. If they were paranoid, did you cho= ose communication methods that made them "more" paranoid perhaps= ? If they were proud, did your communications methods make them defensive?<= span style=3D'mso-spacerun:yes'> Could there have been a bette= r way to handle them? What mad= e them proud? Was it false pride that they were defensive about? Did they view us very competitively? Were we threatening in other ways?
- Again – make them look good.=
If we invited Company666 to= do a brown bag on Product5. And in return, we could do a brown bag on something = we do if they like the idea. What we did do was to arrange overall training fo= r COMPANY999 as well involving other 3rd party vendors – share the credit and shar= e the responsibility.
2.1.4.5 Why build relationship? What does= this achieve?
- This strategy allows us to develop "real" frien= dship with the "real" people on the other end of the stressful and potentially backstabbing email thread! We become a real face, a real= person, who as a real person is much more difficult to screw over in a project= .
- 3rd party vendors want to help you, the client and the pr= oject – decrease risks, dependencies and delays.
- Get early inside information about what is happening with= them and therefore can plan timelines and dependencies better.
- Get a crucial perspective about the client from 3rd party vendor point of view.
- In a position to offer advice as to how they should run t= heir project. Sometimes, we m= ight even help them save the vendor by pointing out something that they are doing wrong or something that they overlooked. Get involved with their stuff. If they are threa= tened, soothe them. If they are secretive, make them trust you. Whatever it t= akes, get inside.
- If advice' comes from the the_company's perspective. It c= an be structured to support the best interest of the_company AND theirs. We = may even get them to do work for us.
- Become friends with the client so they will talk to you b= efore assuming the other vendor is right. The worst thing that can happen is that they believe the other vendor and then start telling their boss t= hat it was us that were at fault. When they get the real story, they will likely not go back to their bosses and admit to the real problem especially if it was resolved.
PMs on a= client side are usually quick to tell their boss who was at fault but are not quic= k to fix the story to their boss if they were wrong in their assumption because:=
1. = It requires additional en= ergy.
2. = Makes them look worse in = the eyes of their boss that they misdiagnosed the cause so the next time around, their boss won't recommend the_company to another department that may be looking for a web solution.
But, ALW= AYS be moral and retain your integrity as an individual and as a representative of= the company. Don't lie. Don't screw other vendors over. Lo= ok for the win-win - talking about building business relationships. And those relationships are always based on trust, performance, and reciprocity.
2.1.4.6 Documentation and Processes.
- During the project: have extra meetings and documentation (weekly status reports, minutes of meetings, paper trail to the right people) and follow up to make sure everything went smoothly.
- Keep all parties informed and recognize the No Surprises = method of Project Management with 3rd Party Vendors. Everyone is more understandin= g of known delays or problems than if their back is against the wall. If there is a risk in a status report or meeting minutes, it should not just be highlighted in the report, but followed up with a phone call to the PM on their side to m= ake sure they understand that risk.
- There are also client management strategies (like face to= face meetings to review progress reports) and motley other things that we c= an, as a group, come up with – brainstorm with your team of PMs and developers. Think like c= hess players or army generals, or Aikido masters. Be strategic. Negotiate hard.=
- Good documentation is our final protection against bad 3rd parties and clients and it is a CRUCIAL part of project management. Wh= ile documenting is crucial, relying on documentation to solve 3rd party problems should actually be our VERY LAST line of defence.
If process is not smooth:
- Assess the situation themselves and come up with a soluti= on to rectify the problem. As = each project is inherently different, the solution will be different.
- Follow procedures and document everything as religiously = as possible to the network.
- Document and explain to the client what he needs even tho= ugh it falls out of the scope of our duties.= Assume the role of a consultant to advise client in a non-parti= al way. Do not play politic= s.
2.1.5 = Compliance to the_company Standard Operating Procedures
the_company’s success with projects is not simply due to the fact that we hire great people. It also has to do wit= h the processes we have set in place to assure that great people do great work. Y= ou will be expected to read the Project Manager SOPs (I am glad that you are reading it now!) but will especially be responsible for:
- Weekly Progress Repo=
rts.
- Weekly Project Manag=
ers
Meetings.
- Saving Project relat= ed documents (especially ones that might be involved in legal disputes) to the NT drive.
2.2 Se= nior Project Managers
The senior the_company project mana= ger will have all of the responsibilities of the the_company project manger but will= :
- Be required to run multiple simultaneous projects<= /li>
- Be required to provide mentorship for new project manager= s.
2.3 Pr= oject Directors
The role of the Project Director is= to manage the team of project managers (provide checks and balances) and to provide an interface to the rest of the organization.
2.3.1 = Project Director as Line Manager
At a minimum, the role of project d= irector is one of line management for each of the project managers at the_company.<= span style=3D'mso-spacerun:yes'> As such, you will be responsible f= or:
- Providing recommendations to upper management in terms of promotions, raises, and official scolding or punishment.
- Dealing with HR administration issues such as vacation requests, performing quarterly one2ones, and working out personal issu= es.
Further, as you can see, the role of project manager is pretty broad and each PM is responsible for performing a wide set of tasks. It is your= role to be looking over the shoulders of your PM’s. You need to make sure that each PM= is doing everything he or she is supposed to do. Because of the complexity of = the project manager role, your PM’s will need constant checks and balance= s.
2.3.2 = Project Director as Team Lead
You will also be responsible for the project managers as a group. = As such, you will be responsible for:
- Developing a growth plan for your group.
- Training of the project managers.
- Recruiting additional project managers according to your = growth plan.
- Running weekly project management meetings and providing = notes for all staff.
Further, you will ultimately be res= ponsible for the success of ‘all’ the_company projects. That means that = you must be able to track every project as it interacts with all other projects. You must know where all of the project resources are at every stage and whe= re conflicts may arise.
In fact, you are expected to be one= step ahead of all projects and have the experience to know in advance when confl= icts are brewing. Whereas the project manager’s role is to control a single project, yours is to control the whole set of projects.
You will be expected to work with a= ll your project managers to assure the most efficient use of resources between all projects. Keep in mind that projects are global.
2.3.3 = Project Director as Agent of Upper Management
You will also be responsible for re= porting to senior management team on the progress of projects. As such, you will have to provide a progress report each week that communicates the important risks, dependenci= es, and status of all of the projects.
2.3.4 = Project Director and Accounts Receivable
The flow of cash is what makes the = company survive and billing is one o the MOST important roles in the company. As it so happens, this is one of y= our key roles. Managing accounts receivables means that you know exactly when to bill each client for each project and that you make sure that the project PM gives the accounting department (Rita) enough time to invoice the client.
Further, because all clients are sn= eaky, you must follow up on all unpaid invoices once they are late. This is a critical job and must be= daily on your mind. Late payments c= ould easily kill a company.
2.3.5 = Project Director as Client Relationship Manager
As the senior projects person on any project, you should make sure that you spend enough time schmoozing the head person on the other side. As mentioned earlier, our projects team is one of= our most important sales channels. We depend on you to make follow-up sales.
All the same rules apply to you as = were applied to the project managers. Maintain good communication and use one2ones and progress reports as tools to ensure trust and confidence.
3 The = Project Lifecycle
3.1 Pr= e Sales
At this stage, the initial sales co= ntact has been made. The sales pers= on would have done the following:
- Created a new folder in \\nt\Data\projec= ts\Projects_pitching
- Created a blue folder hard copy folder
- Assign a project code to the project
The format of the project code is as follows:
COUNTRY/5 digit Serial Number/Proje= ct Type Code
E.g.
SG/00018/TC
There is a log that keeps track of = the project codes which is used by the sales department. Further explanation of the project= code can be found in that logbook.
3.2 Po= st Sales
At this stage, both party, the clie= nt and the_company would have signed the proposal as an indication that the sales is closed and the project is ready for development.
After the sales deal has been compl= eted, the PM will take over. Here i= s the documentation that needs to be done:
- Move all hard copy documents in the blue file to the blac= k file and sort them according to the TOC located at \\nt\Data\projects\ProjectAdmin_Gen= eral\IndexofContents.doc. After you have sorted out the= black file and its contents, print a label for the black file. The label template is located= at \\nt\Data\projects\ProjectAdmin_Ge= neral\black_file_label.doc.
- Move all soft copy documents in the \\nt\Data\projects\Projects_pitching directory into the project folder at \= \nt\Data\projects. In the project folder, there = are 5 default folder that needs to be created:
- Correspondence – This folder is where all importan= t soft copy email is saved. It= is part of the project documentation to save important email corresponde= nce such as confirmation on tech specs, UAT acceptance, etc.
- Development_Timeline – In this folder you will fin= d the development timeline for the project.
- Proposal_Contract – All proposal/contract sent to = the clients should be saved here for future reference. The technical lead should re= ad the final proposal to make sure that they know the scope of work that the= _company has to do and the deliverables due to the clients.
- TechSpecs_Development – Once the proposal is signe= d, the technical lead together with the client will flesh out the requirements/functional specification for the project. This is where all files rega= rding the specification for the project, be it technical specs or functional specs, should be saved.
- Minutes – Meeting minutes for the project should be saved here. It is also required to have a hard copy of the minutes in the black file.=
- Testplan_UAT
- Look_N_Feel – This folder keeps the entire HTML, graphics and design concepts that the Creative Department has develop= ed.
- You might want to other relevant folders as the project progress.
Once the proposal has been signed, = the legal department from the_company and the client should start working on the project contract. However, no= t all projects will have a contract. In the case on a “non-contract” project, the proposal will server = as a contract.
3.3 Pr= oject Specifications
This is the stage where your team a= nd the client will sit down and detail out the requirements of the project.=
It is important that every detail a= bout the project be documented in the Requirement Specifications document because yo= ur developers will use this document as the project bible (everything within t= he document will be completed and anything not contained in the document will = not be considered a deliverable).
It is crucial that the client’= ;s team reviews this document and agrees that it represents their understanding of = the project as well. In order to = make sure that the client understands the document, you and your technical lead should go over the requirements specifications document with the client pag= e by page, asking question and explaining all points.
It is important to note that this i= s a requirements specifications, not a technical specifications therefore it mu= st be written in as non-technical as possible. As not all clients are technically inclined, you must make sure that your technical lead does not put too many technical jargon in the document which can make the requirements specificat= ions difficult to understand by a non-technical person.
3.3.1 = The Requirements Specifications Document
At this stage, the technical lead w= ith the help from the PM and the client will flesh out the Requirements Specificati= ons for the project. The template= for the Requirement Specification is located at \\nt\Data\projects\P= rojectAdmin_General\Requirements_Specification_template.dot
The initial version of the Requirem= ents Specification should be drafted by the technical lead. Subsequent amendments can be done = by either the PM or the technical lead. A document revision page is used to control the document version so = that the project team members know what changes has been done to the specs.
Below is a brief description of the document revision standard:
Version
Date
Description
Author
- Version – This will indicate the last version of the document when it was updated.
- Date – The date when the update was made.
- Description – A brief description of the changes ma= de to the document. This should preferably include the section where the changes were made.
- Author – The person who made the changes.
It is very important that all quest= ions are answered at this stage and all grey areas are defined properly before development can commence. Thi= s is to avoid misunderstanding in the future when the application is delivered.<= /span>
The process of defining the specs w= ill usually take about 3 weeks to complete.&nb= sp; Once the requirements specification is finalised, the client has to = sign and approve the specs before the development can start.
The signed and approved copy of the= specs should be filed in the black file.
Although the requirements specs has= been signed and approved, changes to the specs can still be made at a later stag= e if both the client and the_company agrees with the changes. Once there is a change to the spec= s, a copy of the specs MUST be given to the client.
It is preferred that a PDF version = of the specs is given to the client instead of a DOC version. However, not all clients have a PDF acrobat reader.
3.3.2 = Determining the version of your specification document
When you start writing your specs, = it is in version 0. The initial draft = would carry version 0.1. As you add= more to the specs, it would increment by 0.1.&n= bsp; Your specs will always have version less than 1.0 until you have giv= en it to the client for their first review.
After you have given it to the clie= nt for review, it will start with version 1.0.&nb= sp; When there is a small/minor change to the specs, the version would increment by 0.1. Whenever th= ere is a major change to the specs, the version would increment by 1.0.
For example, if there were a new fi= eld to one of the existing report in the application, then it would be a minor change. So you specs would ch= ange from version 1.2 to 1.3.
If there were a new report inserted= into the application, then this would be a major change thus the specs would cha= nge from version 1.3 to 2.0.
As a rule of thumb, whenever there = is a new section added to the specs, it would be considered as a major change.
3.4 Re= sources Planning and Project Timeline Development
3.4.1 = Resources Planning
The next step is to get the resourc= es to work on your project. The COO= or Project Director does resource allocation for each project. This will be done on a case-by-case basis.
Typically, in a project you would r= equire the following resources:
- A Project Manager (yourself)
- A Technical Lead
- Developers (The number of developers needed will depend o= n the size of the project)
- Graphic designer (Sometimes not required as the client wi= ll provide their own resources for this)
- HTML monger (Sometimes not required as the client will pr= ovide their own resources for this)
- System Integration Support
Note that sometimes, a resource may= be assigned to multiple projects at one time.= It is the job of a PM to discuss among each other on allocating the shared resources and inform the resource accordingly. Should there be a conflict on this matter, the COO or Project Director will resolve this.
3.4.2 = Project Timeline Development
After the requirements specificatio= n has been completed, you and your technical lead should have a clear idea of what the deliverable are. Therefor= e, this is a good time to draft out a development timeline for the project.
The timeline should include a break= down of all modules that need to be developed.&nbs= p; This timeline breakdown should be a guide for you to do a weekly mee= ting to see if the project is on track and if there is any possible delay.
One of the many good tools in devel= oping a schedule/timeline for your project is MC Project.
When preparing the timeline, use the questionnaire below as a guide to make sure that it is as complete as it can be.
3.4.2.1 THE_COMPANY TEAM
Did you schedule your developers?
Did you schedule the infrastructure= team?
Did you schedule the design team?
Did you schedule Functional Specifi= cations?
Did you schedule Internal Testing?<= /span>
Did you schedule Client-site UAT?
Did you schedule time for documenta= tion?
Did you schedule time for cleanup a= nd Productization?
3.4.2.2 IMPORTANT DEADLINES
Are all your key milestones include= d?
Have you noted vacations and holida= ys of key people?
3.4.2.3 MARKETING
When should the_company announce la= unch?
When will the client require market= ing demo?
When is the client success story sc= heduled to be written?
3.4.2.4 UAT TEAM
Did you schedule the client-side UA= T Team?
Did you schedule training for them?=
3.4.2.5 THIRD PARTIES
Did you schedule 3rd party develope= rs, infrastructure guys, and designers?
Did you factor in legal dependencie= s?
Did you factor in audit dependencie= s?
Did you factor in related the_compa= ny projects?
Did you factor in the client-side P= roject Manager?
Did you factor in content developme= nt and editing?
3.4.2.6 PRODUCTION MIGRATION
Have you checked with the client the required paper work to productionise the application?
Did you schedule in the required documentation for production migration approval?
3.4.3 = Introduction to MS Project
MS Project is a good Project Manage= ment tool. It allows you to manage= the following efficiently and effectively:
- Man days for each major task/milestones
- Start and End Date for each task.
- Linking 1 task to another.
- Resources assigned to complete each task.
- Deadline management
3.4.3.1 Man days management with MS Project
There is a column in MS Project, wh= ich will calculate the number of man-days it will take for each task to complete.
3.4.3.2 Resources management with MS Project
In MS Project, you can assign resou= rces to a task. With that resource, y= ou can also assign the percentage that each resource will be working on. To assign the above, use the Task Information function and select the RESOURCES tab. See diagram below.
![](3D"pm_sop_20020812_files/image002.jpg")
3.4.3.3 Linking 1 task to another using MS Project
One of the useful features of MS Pr= oject is the ability to link 1 task to another.&nbs= p; This will allow you see the real deadline for each task and task rel= ated to each other.
As some task may not be developed concurrently with other task and must wait for one task to finish before it= can start, you can use the PREDECESSORS column to link them together. Each task is assigned a task numbe= r and to link one task to another, simply put the task number that this task is linked to.
3.4.3.4 Start and End date management with MS Project
The column Start and Finish is automatically calculated according to the number of man-days entered in the DURATION column.
This is a good tool for you, as a P= roject Manager to get your developers to fill in the number of days each task will require. After which all you = have to do is to enter in the start date for each related task and you would hav= e an almost complete schedule/timeline for your project.
3.4.3.5 Deadline management with MS Project
Using the Finish date column, you c= an construct a deadline for each task/milestone. This will allow you to track the deadlines easily.
3.4.4 = Introduction to MS Visio
As you can see from the MS Project introduction above, it can be quite confusing and time consuming to understand. Most of the time = the client would like an easy to understand timeline without too much detail.
The Visio timeline consist of 6 sec= tions:
- the_company Team
- Client’s Project Management Team
- Client’s Marketing Team
- UAT Team
- Third Parties
- Important Deadlines/Milestones
The the_company Visio timeline is u= sually attached with the weekly project progress report. You should always send this as a P= DF or a JPG as not every client have Visio or Acrobat reader.
3.5 The Development Phase
During the development phase, it is important that you keep track of the progress of the application development. It is easy for y= our developers to lose track of time and they may be behind on the schedule.
3.5.1 = Ping your developers
It is important that you constantly= ping your developers to find out how they are progressing on the application development. Your developers = should have a copy of the latest schedule and timeline. This way they can let you know if = they are behind schedule.
The best practice is to have a brie= f chat with them every week to find out where they are on the development stage.
The template for the Developer Prog= ress Report can be found at
\\bacchus\data\templates\developer_progress_report_tem= plate.doc
3.5.2 = Using CVS to keep track of the development progress
The project CVS commits can also be= used to gauge the progress of the development.&nbs= p; A good gauge of progress is to read the CVS Commit log messages beca= use they usually say things like "Added feature to do XYZ".... which usually relates to your project plan.
CVS commits should happen on a dail= y or every two days basis normally. If it happens only once a week on a 2 develo= per project, they are likely going to cause problems for each other that are ha= rder to resolve 5 days later than having done regular commits and updates where = they are forced to integrate sooner.
CVS enforces a certain discipline a= bout coding which helps in multi-programmer projects in this way.
3.5.3 = Coordinating all departments involved
The project will not only involve t= he developers but it will also involve other departments like the Look-N-Feel department and also the Admin department.&= nbsp; It is your job to coordinate all departments involved.
For example, you need to make sure = that the Art department completes all the Look-N-Feel requirements such as the graph= ics, HTML, etc. for your developers. This is so that your developers can concentrate on the development of the application instead of the Look-N-Feel stuff.
It is also your job to make sure th= at resources from other department do not conflict with your resources. For example, the Art department ma= y be working on other projects as well so it is important that you coordinate wi= th other project managers to make sure that resources are well distributed.
3.5.4 = Working with clients
During the development phase, it wo= uld be ideal if you can deploy part of the application to the client’s environment for them to test it out. This is so that they can have a chance to comment on the application= . Getting feedback at an earlier sta= ge is better than getting them during the UAT period because by UAT time, it woul= d be too late to make changes to the application.
The above includes getting confirma= tion from clients on the HTML that was developed. Once the HTML are approved, they c= an be passed to the developers for implementation.
You need to also work with the clie= nt to keep them up to date on the development progress. This can be done via the weekly pr= ogress report. You can also take the= m out to lunch or dinner and just have a casual chat about the progress.
3.5.5 = Organise and manage unit testing with clients and third parties
In big projects you may sometimes n= eed to organise a mini “UAT” in between the development stage. Once a major milestone of the application is completed, it is always a good idea to install it onto the client’s development/test environment to do a simple unit testing.
This unit testing need not be a full UAT. All it had to do is to t= est the completed module. This wi= ll give you a chance to see if the application is working according to the spe= cs and it will also allow the client to have a feel of how the application will work when it is completed.
Sometimes unit testing will involve= third party vendors. It is you responsibility to coordinate with the client and the third party vendors to make sure that the unit testing is done.&n= bsp; You must make sure that all third party vendors involved be ready and that their components are ready to integrate with your application.<= /p>
Coordinating with the_company’= ;s infrastructure team is also important.&nbs= p; In certain project, big ones especially, you will probably need an t= he_company infrastructure techie to help you integrate your application to the client’s development/test environment. You need to make sure that the infrastructure team is aware of this and arrange meeting for them to meet w= ith your developers so that the infrastructure team knows what to do.
3.6 Te= sting (UAT and Unit Testing)
There are 2 phase in a UAT:<= /p>
- The test plan development phase
- The testing phase
3.6.1 = The test plan phase
Before a UAT can start, the tester = will need to have a step-by-step guide on how to test the application. The test plan serves as a guide to= the tester on how to do the testing.
The test plan should document the a= ction that the tester need to do and also the expected result. It should be idiot proof, i.e. it s= hould assume that the user does not know how to use the application at all. It should tell the tester where to= click and what to input into the input fields.
The test plan should be developed u= sing the ALPHA release of the application from your developer. By this time, your developer shoul= d have a working application for you to test on.&= nbsp; It is OK if the application is buggy but at least you will know what steps the testers will need to take to complete the UAT.
This also gives you an opportunity = to detect bugs before the client themselves detect them. Detecting bugs before the UAT peri= od will allow you to plan and warn/prepare your clients for it.
A sample template of a test plate is located at \\bacchus\data\projects\ProjectAdmin_General\Test_Plan_template.doc<= /a>.
A good example of a good test plan = can be found at \\bacchus\data\projects\Company999\COMPANY999iz\Test_Plans\Functional= _Test_Plans.
The test plan should be ready at le= ast 1 week before the project UAT period. Both the client and the_company should have reviewed the test plan a= nd agreed on it before the test plan can be used for testing.
Note that each test case should car= ry a priority and the priority is defined at the end of the test plan.
3.6.2 = The testing phase
Before testing can start on the cli= ent side, a Bug Tracker for the project must be setup. The Bug Tracker is important for e= very project as it acts as a control centre for all bugs that were reported duri= ng the UAT period.
To set up the bug tracker, you need= to get the help from the Infrastructure team who takes care of the the_company.com= website.
3.6.3 = Prioritising your bugs
It is important to prioritise each bug reported so that your developers know which one to concentrate on first.
3.6.3.1 Priority 1:
Priority 1 reports include any error or bug that fatally affects the core functionality of the application, defined within the original specifications, such that the user is unable to use the function. Priority 1 reports are to be fixed= by the live launch date. Priorit= y 1 reports that have not been fixed are grounds to refuse User Acceptance and delay the launch date.
3.6.3.2 Priority 2:
Priority 2 reports include any error or bug that does not affect the core functionality of the application such that the user is still able to perform the primary task of the application. Priority 2 reports do not need to = be fixed by the launch date and do not form a basis to refuse User Acceptance = and should not delay the launch date. Priority 2 reports may include bugs/errors that occur due to a varia= tion to the original specifications. the_company will make every effort to rectify Priority 2 reports as soon as possible.
3.6.3.3 Priority 3:
Priority 3 reports include any error or bug that does not affect functionality of the application and that may have arisen from variations, additions or changes to the original scope of works, including but not limi= ted to graphics and look and feel. Priority 3 reports will not affect User Acceptance and/or the launch date. the_company will make e= very effort to rectify Priority 3 bugs within regular working hours.
3.6.3.4 Priority 4:
Priority 4 reports include any error or bug = that does not affect functionality of application and that may have arisen from variations, additions or changes to the original scope of works, including = but not limited to graphics and look and feel. Priority 4 reports will not = affect User Acceptance and/or the launch date.&nb= sp; the_company will make every effort to rectify Priority 4 within the warranty period.
3.6.3.5 Priority 5
Priority 5 repor= ts are reserved for reports marked FIXED.
3.6.4 = Coordinating with your client’s testers and third parties
In order for you to have control over = the UAT process, you need to control your client. You need to brief your client abou= t your testing procedures. You need = to tell your client that they need to elect a BugMaster.
The BugMaster’s job is to replic= ate bugs reported by the testers and key them in the bug tracker. It is very important that each bug= can be replicated before they are entered into the bug tracker. Bugs that cannot be replicated can= not be debugged.
It is also important to note that ther= e is only 1 BugMaster entering the bugs into the bug tracker. This is to avoid duplicate bugs in= the bug tracker.
You should also coordinate with all= third parties involved. You will pr= obably need their support during the UAT period.&= nbsp; There maybe times when a bug is not due to the_company’s application fault but a third party application problem.
3.6.5 = Managing the UAT environment
During the UAT period is where R= 20;all hell break lose”. This = is the time when your developers will feel the pressure and morale will be down.
You should make known to them that = if they stay late, they can claim the taxi fare from the project fund. The same goes for food. They can claim from the project fu= nd if they have to stay late to work on the bugs. Make sure that their stomach is al= ways filled! Make sure that there = are always drinks in the fridge, candy on the counter and that they know the numbers to the food delivery service around the corner.
Not only should you take care of yo= ur developers, you should also make sure that the client is happy. During the UAT period clients̵= 7; mood will be frayed, as they too will have to deal with their boss and the marketing department’s pressure.&nbs= p; Make them feel that they are doing a good job. Give them positive input and try to resolve issues with a win-win situation.&n= bsp; Take your clients to lunch and dinner.
Besides your developers and your cl= ients, you need to also manage your third party dependencies. As your project depends on third p= arties support and delivery, making them happy will make your UAT a lot smoother.<= /span>
3.6.6 = Daily UAT Report
During your whole UAT period, it is= always a good practice to record down your daily events. This will allow you to communicate= to your client on what actually happened during the whole UAT period.
Daily UAT reports can be submitted = daily to the client to for review or it can be attached to the Status Report as an Appendix.
Below is a sample Daily UAT Report:=
Time
Description=
1
9:15AM
KKK arrives.
2
9:30AM
As Product5 was down from 6:00AM till = now, there was a lot of email sent to the Customer333 admin (on test, it is ZZ= Z, KKK and WWW). These emails are = sent to the admin whenever the eZeeTrade application detects that the connecti= on to the backend systems (Product5/RPI/Product9) is down.
An email will be sent whenever the pol= ling engine detects that the backend systems cannot be connected to. As the polling is configured to = poll every 5 minutes, therefore an email is sent every 5 minutes until the bac= kend system is up.
This is an interesting test yet again = as it replicates a real situation when connection to the backend system is down. As the queuing engine= is configured to know that Product9 will be shut down everyday from 8PM till 6AM, no email was sent during that time.
This is also a prove that shows that t= he Queuing engine is working as specified in the specs.
3
10:00AM
Stephan called to inform that the “Place of Expiry” field is hard coded on the RPI components.<= span style=3D'mso-spacerun:yes'> As GGG has suggested a new list = of “Place of Expiry” for the application, this new list will not= be able to be populated to Product9 automatically until Company5 and Company= 666 make their necessary changes. Changes will also have to be done on the_company’s RMI engin= e.
As it is important that the new list be implemented as soon as possible, GGG and KKK came up with a temporary solution. The new list will= be implemented on the front end but at the backend the “Place of expiry” field value will always be sent into Product9 as “BENE” as currently. When the Customer4 personnel receive the SSS application, they will have to manually change the “Place of expiry” value on Produc= t9 to whatever the user has keyed in on the SSS application form.
As most of SSS application will use BE= NE, we do not see this as a major issue.&nbs= p; This temporary solution will be resolved when Company4 and Company= 666 has done their changes.
As this change is minor and is covered= in Phase 1, we do not see why COMPANY999 has to pay extra for this change. <= span style=3D'mso-spacerun:yes'> However, this is still pending RP= I and Company666’s confirmation.
3
11:30AM
Latest patch arrived. The patch was successfully insta= lled at 12:30PM and UAT resumed to test the latest patch.
4
1:30PM
The latest patch solved all the bugs a= nd the Queuing engine is now ready to migrate to production.
As for the “Cannot Submit”= bug discovered 2 days ago, it was not actually a bug. It was a user error. Below is a brief note about it:<= o:p>
More investigation was done on the “Cannot submit” bug. With MMM’s help we went into the Product6 Admin to check the approval limit for John Samy. We found that the approval limit for ZZZ on Product8 is 66 million RM but he only has an approval limit of RM100,000 for all Product555 application.
We changed the the approval limit for = ZZZ on all Product555 application and he was able to approve an SSS applicati= on with amount greater than RM100,000.
5
3:00PM
More UAT went on to test the reports a= nd the queuing engine.
6
3:30PM
Preparation of production migration documentation. Documents pr= epared were UAT test plans and also test results.
AAA has been tasked to prepare the oth= er 2 documents:
- Migration check list
- Enhancements on the Product000 application
7
4:00PM
Some discussions were done regarding t= he system failure notification email. FFF said that it would be quite annoying to be receiving email eve= ry time the polling engine detects that the backend is down. As with yesterday’s test, = there were approximately 200 emails sent to Customer4 personnel (for testing
FFF suggested an alternative. When the polling engine detects = that the backend is down, an email will be sent. No more emails should be sent un= til the system is back up.
Therefore, when an alert email is sent= to the Customer4 personnel, it is assumed that the backend system is down un= til the “up” again email is sent.
KKK will check with LLL to see if this= can be implemented.
3.6.7 = Unit Testing
Unit testing is a test phase for ea= ch module as they are being developed. Unit testing can be done either on the_company’s environment o= r at the client’s environment.
Sometimes in a big project, unit te= sting is necessary. Unit testing are u= seful to make sure that no surprises will happen when the actual UAT takes place.
Unit testing can also be useful to = gather client feedback on the application that has been developed so far. It is better to get feedback at an earlier stage than at a later stage when a small change to the application = will have a domino effect on the project as a whole.
3.6.8 = Internal Testing
It is important that the_company de= livers a tested application to the client. At least 1 round of internal testing should be done at the_company before delivering the application to the client.
This is to make sure that there are= no silly bugs, which may embarrass the_company. Internal testing is also crucial f= or the_company to identify existing bugs and pre-warn the client of the bug and that we are working on solving the problem.
3.7 Do= cumentation, Training and Handover
3.7.1 = Documentation
Documentation is a very big part of= the project. After the project is completed, you need documentation so that the client knows how to administer and maintain the application. Thee are 2 types of documentation:
3.7.1.1 Technical Documentation
Usually the lead developer will be in-charge of writing the technical documentation. This document will include all the technical bits about the application. Information such as the directory structure, the application design = and also troubleshooting tips should be included.
3.7.1.2 User Manual and Guide
Not all projects will require user manual. Sometimes the client = will have their own team that will come up with their own user guide and manuals. This document will t= ell the client’s users how to use the application.
Usually if the client requires that= the_company provide a user guide, it is usually required to be implemented as a HELP or= FAQ in the application. If this i= s the case, then you will need to help of the Art department. As most help or faq are in HTML, y= ou will need the graphics and HTML from the Art department.
3.7.2 = Training
Training should be arranged also to= ensure that the client’s technical staff knows how to maintain and support t= he application. Most of the time= , the training is held at the client’s office but if they would prefer it t= o be held at the_company’s office, it can also be arranged.
Again, the lead developer would be = the ideal candidate to conduct this training.&= nbsp; It is your responsibility to organise the training, which includes:<= /span>
- Getting the venue ready – Preparing the necessary environment, network, PC set-up, projector, etc.
- Getting the training material ready – Printouts and= other documents.
- Coordinating with clients – If the client is from outstation, you will need to help them get the necessary accommodation, transportation, etc.
3.7.3 = Handover
The handover is usually done after = the documentation and the training has been given to the client. At this stage the client should be comfortable with the application and that they would know what to do in cas= e of any problems that may arise from the application.
Handover will involve giving the cl= ient:
- The contact point to the_company in case they need to con= tact us.
- The escalation procedures which is explained below=
- Online resources that the client can go to if necessary.<= /span>
3.8 On= going Support
Most of the time, the client would = sign a Support & Maintenance contract with the_company so that they can get the necessary support and help when required.&= nbsp; For this purpose, you will require to know the following:
3.8.1 = Assigning a techie for the warranty period
After you have completed t= he project and is delivered to the client, the application is now under a warr= anty period. A warranty period usu= ally comes with every project. It = is negotiated during the sales process and is documented in the project contra= ct.
The usual the_company warr= anty period is 3 months but there are some projects that may have warranty perio= d of more than 3 months depending on the negotiated value in the contract.
During the warranty period, the PM will assign a developer/tec= hie to be “ON CALL” for that project. In case the client reports an issue during the warranty period, you will have a techie to support you.
Some projects may have a special “on call pager” t= hat the client will call. If this= is the case, it is usually the PM, you, who will carry the pager.
3.8.2 = Escalation Procedures
In the event there is a problem wit= h the application, the problem needs to be escalated to the correct personnel.
Usually, there will be an “ON CALL” techie (refer above) on the the_company that you can contact if= a problem comes in. The “= ON CALL” techie is usually listed on the escalation contact information sheet. A sample escalation co= ntact information format can be found at \\bacchus\Data\Administra= tion\Integration_mgt_process.
With that information sheet, you sh= ould have a good idea on who to contact for what problem. In the case it involves a third pa= rty, you can either contact them directly or have the client contact them.
3.8.2.1 Severity Level of problem
Depending on the severity of the pr= oblem, different level of severity will require different response time. This severity level is usually sta= ted in the Support & Maintenance contract.&nb= sp; Below is a sample of the usual Support & Maintenance contract severity level:
Severity L= evel 1
The Software is totally inoperable and the production environment is impaired; certain critical processes have crashed or for unk= nown reasons have failed to start.
Severity Level 2
The Software is operational for the core service, but= ancillary features or less critical features do not work properly or cannot be access= ed.
Severity Level 3
<= span lang=3DEN-GB style=3D'mso-bidi-font-family:Arial;color:black'>The Software = is operational and the problem can be circumvented.
<= span lang=3DEN-GB style=3D'mso-bidi-font-family:Arial;color:black'>
Service = Level
Severity level 1
Response to notification within 1 hour
Response with initial diagnosis within 3 hours
Restoration within 5 hours
Resolution within 2 days
Severity level 2
Response to notification within 2 hours
Response with initial diagnosis within 1 working day<= o:p>
Restoration within 2 working days
Resolution within 4 working days
Severity level 3
Response to notification within 4 hours
Response with initial diagnosis within 3 working days=
Restoration within 8 working days
Resolution within 14 working days
A good example of a Support & Maintenance contract can be found at \\bacchus\Data\projects\more_reward= s\Support&Maintenance\Contract.
4 Repo= rts and Meetings
4.1 We= ekly Progress Reports
Not all projects will require this = but it would be great if the PM can present the customer with a weekly progress re= port on the project. This is to ke= ep both the client and the project team informed on what’s going on with= the project.
The purpose of this document is to = help you control your project through better communication. IT projects are exceptionally complex, but we have found that when done well, the progress report is a very simple tool to control this complexity. Note that “done well” = is critical. When done poorly, progress reports are a waste of everybody’= ;s time. So please take time to make your text meaningful.
Note that progress reports are not = about protecting your ass. The goal is to foster communication and creativity. If= it is used as a weapon, the progress report loses its value.
Progress reports are also not about micromanagement. You are not writing this because your boss does not trust you. In fact, your boss is the least li= kely person to need to read this. It is about communicating valuable information= to your peers who need to coordinate their work with yours, but who may not kn= ow it yet.
Finally, progress reports are not a= bout wasting time. Once you are practiced, a good report should take no longer than 1.5 hours per week to complete. Believe me, if you = add up the time “saved” through better communication and less meetings, you will be saving more like 10 hours per week. Hard-earned experience proves that= the progress report is not wasteful bureaucracy, but a productivity-enhancing t= ool to help you perform better.
So please take time to do a good jo= b and please re-read the instructions for each section every week in order to rem= ind yourself of what you need to write. Finally, please “demand” feedback from your readers. Their job of reading cannot be passive. If it is, neither of= you will improve.
Every Thursday afternoon, you shoul= d pass your draft progress report to 1) your client-side PM so that they have a ch= ance to read it before their boss does, 2) KKK, so that the design team can have input, 3) CCC, so that the infrastructure team can have their say,4) BBB, so that the marketing departm= ent can be ready to market your successes, and 5) AAA, because he always has something to say. Then, inclu= de the comments in your final daft and send it to the project director, DDD by Fri= day night. Finally, save your report to the network for posterity.
The progress report consists of the following sections:
· Update Summary
In this= section you should provide highlights of the week, success and failures, deliverabl= es met, difficulties overcome, disagreements resolved, disagreements introduce= d, clarifications of specifications, jargon defined, and advice to clients.
· Client To-Do Items
What is= it that the client needs to do next week? Infrastructure (network, hardware, software), content development, deliver designs or graphics, 3rd party issues, set up meetings, legal, signoffs, documentation, marketing/PR, testing. Be sure to specify who is to complete the item and by which date they are supposed to complete it. Mark in red, items carried over fr= om last week.
You sho= uld format your items using the table below:
Action Item Description
Who must complete the item
Who will verify completion
When must the item be completed
Item in= the table should be sorted with the latest item first.
· the_company To-Do Item= s
What is it that we are sup= posed to deliver next week? Software components, documentation, testing, meetings, infrastructure. Who is going = to be on the client site next week? Mark in red, items carried over from last week.
You should format your ite= ms using the table below:
Action Item Description
Who must complete the item
Who will verify completion
When must the item be completed
Item in the table should b= e sorted with the latest item first.
· Dependencies
What ar= e you depending on that might affect your ability to deliver? Infrastructure (network, hardware, software), content development, design, legal, other the_company projects or developers, other projects being done by the customer, 3rd party vendors, t= he client’s IT team, the client’s testing team. Remember, you must give a dependent party fair warning. If you expect to begin testing for example, the client’s UAT t= eam must be warned 3 weeks in advance, and be reminded each week until testing = starts. Mark in red, items carried over from last week.
· Risks
What is= sues, if not sorted, could cause significant delays? For example, there is a risk th= at GovernmentBodyA might issue a policy statement outlawing the use of digital certificates. M= ark in red, items carried over from last week.
You sho= uld format your items according to the table below:
Risk
Origin
Delay %
Priority
Mitigation
· Completed Milestones
Every project must be driv= en by milestones/ In this section you should maintain a growing list (don’t erase) of milestones completed. Specify the date when the milestone was completed and signed off by the client and indicate if the milestone delivery was early, on-time or late.
You should format your ite= ms using the table below:
Milestone
Target Completion date
Completed?
Item in the table should b= e sorted with the latest item first.
· Variations<= /p>
This is= one of the most crucial sections of the progress report! Include here clarifications of the specs, new features added to the specs, work done for free (however trivial= ), work done as formal additional works, graphics and content/editorial delive= red, training, support of 3rd parties, consultation, and advice. This is a growi= ng list of COMPLETED variations. You should never erase an item here once you have added it. Be very clear how m= uch time was taken to complete the item and if the overall project timeline wil= l be affected.
You sho= uld format your items using the table below:
Description
Date requested
Date Completed
Time Required
Fee
Notes
![3D"[new]"](3D"pm_sop_20020812_files/image003.gif")
Item in= the table should be sorted with the latest item first.
· Additional Works
In this= section, you should mention proposed or in-progress additional works requested by the clients. This could include consulting, design, architecture, content, help with third party vendors, infrastructure, or anything else not explicitly covered in the functional specs. Each item should include: 1) Additional Work Description, 2) Schedul= ed to begin, 3) Scheduled to end, 4) Cost (Man days), and 5) Impact
· Delivery Schedule Chan= ges
Has delivery been changed = by events of the week? Do these delivery slippages affect the overall project deadline? What caused the delays? Will there be a cost associated with the timeline?
You should format your ite= ms using the table below:
Project Name:
Original Proposal Date of delivery:
Reason for delay
Approved by
Revised Delivery Date
· Appendix
Please cut and paste important emai= ls, minute text, or other documents that you would want to be sure were communicated to all parties as an individual appendix. Remember that progre= ss reports are public knowledge so do not include any sensitive information.
4.2 On= e-to-one’s
the_company is always hungry for fe= edback from the client and third parties. Therefore it is your job as the project manager to get feedback from= the client. You can do this via meetings with the client’s team or simply just do a 1-to-1 with the client.
During a 1-to-1 you need to find ou= t what the client thinks about your project team.&nbs= p; The client will usually tell you what he thinks is great about the t= eam and also what needs improvement.
You can also do a 1-to-1 with third parties.
After you have done the 1-to-1, you= will need to spread the feedback to your team.&= nbsp; Remember to always spread both the positive and negative to your team. Don’t just concen= trate on the negative, as they will de-motivate your team. Give them the good news and then t= ell them what they need to improve on.
4.3 We= ekly Team Meetings
Having a weekly project meeting wit= h your team member will help you manage your project team better. Weekly meeting like this will help= you communicate client’s thought back to your developers.
It will also help you keep track of= what your developers are doing. Th= is way if there is any foreseen delay you can warn all parties involved as early as possible so that the necessary action can be taken to minimise a little surprise as possible.
4.3.1 = Meeting Structure
In the weekly team meeting, you wan= t to make sure that you do not waste too much of your team’s time as they = will need to get back to working on the project to avoid any delay in the projec= t.
An ideal weekly team meeting should= not last longer than 1 hour.
4.3.1.1 Who should attend
The main attendees would be all your developers, the art person in-charged and the infrastructure person in-charge. The art and infrastructure personnel may not be necessary in all meetings. Once their role in the project is completed, they may not be required to attend these meetings.
4.3.1.2 Agenda and keeping to the agenda
Just like any other meeting, we sho= uld always have an agenda when we have a meeting. As a project manager, it is your d= uty to prepare the meeting agenda and give them to all your intended attendees so = that they will come to the meeting prepared.
In order to keep the meeting effect= ive and efficient, you need to control the meeting and make sure that it keeps to t= he agenda.
4.3.1.3 Meeting protocols
Meeting pro= tocols can help you control the meeting so that it does not drag too long and out of topic. The most common practi= ce is to choose a chairman which will moderate the meeting.
4.3.1.4 Action plans and items
As with all meetings, there will al= ways be action plans and items that need to be done from the meeting. As the project manager you are responsible to keep track of all the action plans and make sure that they a= re executed.
If there are items that you need to= get from the client or third parties, you need to make sure that they are done = by the timeline stated in the action plan.&nb= sp; Usually these items are queries or confirmation that your developers need, without them they cannot continue with their work.
4.4 Me= eting minutes (with clients and third parties)
Every meeting with the clients or 3= rd party vendors should be documented with a meeting minutes. The template for the meeting minut= es is located at \\nt\Data\projects\ProjectAd= min_General\Minutes_of_Meeting_Template.doc.
Basically, there are 3 columns in t= he meeting minutes:
· Item number – This = is to allow easy referral of items in the minutes in case there is any comments t= hat the meeting attendees might want to add.
· Description – The c= ontent of the issue discussed.
· Action Plan – This = will include a date and what action must be done for that item discussed.=
Usually, item number 1 in the meeti= ng minutes will be a brief summary about the meeting.
The meeting minutes should not only= include the action items for all parties involved, it should also include all issues discussed and agreed upon. The basic rule of thumb is that the meeting minutes should reflect what happene= d in the meeting, i.e. if someone who is not in that meeting were to read the meeting minutes, he or she will be able to picture what was discussed in the meeting.
Once the PM has prepared the initia= l draft of the minutes, a copy of the minutes should be sent to everyone who attend= ed the meeting for feedback/comment/changes that the attendees may have. You should give them about 24 hour= s to comeback to you. You should s= tate that if you do not receive any feedback from them by COB tomorrow, the copy that you just sent would be the final copy.
Once everyone has agreed on a final= version of the meeting minutes, they can sent the meeting minutes their to their respective superior or other parties deemed necessary.
On the next meeting with the client= , the meeting minutes should be brought up again to follow up on the action items= to make sure that all action items are being worked on or delivered on time.
5 Proj= ect Risks
In the course of any project, there= will develop project risks.
Simplistically, project risks inclu= de anything that will cause our inability
to deliver the project on time, on = budget, and up to the quality statndards
the_company requires.
5.1 Ri= sks from the_company
Project risk can come from inside t= he_company.
For example, with such a small staf= f and so many projects going on concurrently, resourcing is always a huge risk for a= ny project. That is, at any poin= t, a key developer on a project could be borrowed for another, higher priority, project. Further, key infrastructure or design resources may not be available when they are needed because they are being deployed elsewhere.
5.2 Ri= sks from Clients
Project risk can also come from the= client.
For example, the client may change = or misunderstand a key requirement. Similarly, there could be a major organizational change in which key personnel in the client's team could eit= her move to other departments, go on holiday, quit, or be fired. Further still, documents that requ= ire signing can be delayed, Client-side office politics could delay things, and= new requirements could be introduced by other departments at the client side at= the last minute.
5.3 Ri= sks from Third Parties
Project risk can come from third pa= rties.
For example, a third party may not = deliver key technology, design, or content on time. This could be a third party techno= logy vendor that does not implement their technology on time or it could even be= a third party legal firm that does not deliver a Support and Maintenance Agreement text in time for the text to be integrated into a website.=
These types of risks are also called "Dependencies". In = fact, these types of risks are so difficult to manage, that we have a separate section in progress reports just for them.
5.4 Ri= sks from Environment
Project risks can even come from the environment.
Government regulations might change= . The economy might crash. War might break out.
5.5 Ri= sk Management
Wherever they come from, project ri= sks will creep into every project. You cannot avoid them.
Unfortunately, the most common reas= on that a project fails is that project risks are not well managed.
One of the differences between juni= or and senior staff is their ability to identify risks and develop strategies to mitigate those risks.
5.5.1 = Risk identification
The first step in risk management i= s to be able to identify the project risks. That is, you should be able to identify what are the significant and potential project risks facing your project at any one time. Of course, this is an ongoing proc= ess; risks will evolve during the course of a project. New risks will develop and existing risks will change in importance.
Identification means being able to = list the risks, determine how likely the risk is to cause a delay, being able to prioritise those risks by danger, and determine what bad things will occur = if the risk is not managed.
5.5.2 = Develop strategies to handle/manage the risk
While I did say that you couldnR= 17;t avoid having project risk, you MUST develop strategies to find ways to:
- Reduce the likelihood that the risk will lead to a proble= m.
- Reduce the damage that the risk will cause if it does occ= ur.
5.5.3 = Example Case Study
Suppose the risk is that a third pa= rty vendor may not deliver the middleware on time.
Suppose that your project timeline = looks like this:
March 01-02 Integration with third party middleware
March 02-07 Integration Testing
March 07-12 User Acceptance Testing
March 13 Launch
As I said, the first thing to do is= to identify the project risks.
In terms of dependency risk, it is = clear that the third party vendor delivers might the middleware late?
Suppose the vendor can only deliver= the middleware on the 6th. What w= ill that do to your timeline? Certainly, this will make it MUCH more unlikely that you will be abl= e to start UAT on time which could then domino down to a late delivery. Late delivery will cost us money a= nd damage our reputation.
Realizing that there is definite ri= sk, you ask the third party vendor how confident they are of delivering their middleware on time. They resp= ond with 70%.
Next, you look at the risk in relat= ion to other project risks you have identified and determine that this is the most damaging risk that you know of.
So, you have identified the risk,
WHAT IS THE RISK:
Middleware may not be delivered on = time which would mean that our application cannot access the legacy applications= we depend on to generate reports.
HOW LIKELY IS IT THAT THE RISK W= ILL CAUSE DELAYS:
70% (as reported by vendor) 80% for planning. Make sure to report both numbers.
HOW DO YOU PRIORITIZE THE RISK:<= /span>
This is the highest priority.
HOW BAD WILL THE RISK BE:=
If we cannot do integration on time, our own UAT will be delayed. Since we are the front-end, delays will "appear" to be cause by us even if it is n= ot our fault. We may have to devote resources to the project longer, which will cost us money. We, and the customer, will lose face due to the late launch.
Now that you have identified the ri= sk, it is time to strategize how to mitigate it.
First you want to see if there is a= way to avoid the risk.
How can you reduce the dependency o= n the middleware? Well, perhaps we = can spend little bit of time developing a component that will "mimic"= the middleware. That is, we can q= uickly develop an engine that will plug in place of the middleware and return to us test data (not actually connecting to the legacy), This will mean that some= of the UAT can go on as intended while we wait for the real component. You may still; lose some time, but= at least you can be semi productive throughout.
You might also see if there is any = way we can help the third party developer to deliver on time. Why are they late?
Keep thinking, be creative, talk ab= out the risk as a team with the infrastructure team, design team, development team, project managers, client, and third party. Communicate!!!
Next, you need to plan for the wors= t-case. Suppose the risk cannot be avoided= . Suppose the UAT is late and the pr= oject is delivered a week late. How do you reduce the damage caused.
Well, for one, you want to make sur= e that the client is VERY aware of the problem and that late delivery is not a surprise. You also want to ha= ve a clear and complete paper trail with all delays pointing towards the third party. You also want to prepa= re the UAT team so that they understand that when the application is not working, = it is not our fault. You need to= teach them about the architecture so that they understand that just because the application is saying it is broken may not mean that it is the_company's bu= g.
Have you notified everyone who need= s to be notified such as marketing?
5.5.4 = Be creative
There are many numbers of things to= do and each project will be different. What is important is that you think smart, think creative, think win-win.
6 Prod= uction Issues and Post Mortems
6.1 Wh= at to do when there is a production issue.
When you application goes live, the= re will be users using the application and as with most application, there are boun= d to be production issue encountered by the users.
Usually, most production issue will= be reported by the user to our client and our client will then come to us for answers. Production issues ca= n be classified into 2 category:
- Warranty
- Support & Maintenance
6.1.1 = Warranty
In most of our contract for project= s, the_company usually give a 3-month warranty period.&nb= sp; However there are cases when the client ask/negotiate for a longer warranty period. If there is a production issue reported during this period, the_company will fix it witho= ut any additional cost.
Once the issue has been resolved, y= ou as the project manager need to compile a report about the incident, which in t= he the_company culture is called a “post moterm”. See post mortem for more informati= on.
6.1.2 = Support & Maintenance
Once the warranty period is over, t= he client might want to sign a Support and Maintenance contract with the_compa= ny. The contract will usually spell ou= t the response time and the service level agreed upon.
For each issue and case that you an= d your team have worked on, you will need to make sure that you and your team memb= ers fill up the timesheets for the work done.
As with warranty issues, once an is= sue has been resolved, a “post mortem” report is required to be written. See post mortem for = more information.
6.2 Po= st Mortem
Post mortems are studies done after= a certain production issue has been resolved. The main objective of a post morte= m is to document the problem and how it was solved so that it will not happen ag= ain in the future or, if it does happen, a resolution is known as soon as possi= ble.
Sometimes a post mortem is not only= for production issues. It can als= o be on an issue that need to be documented and passed around to other member of= the the_company team for knowledge sharing purposes.
Below is a template for a post mort= em report.
Subject
Prepared By
Date and Time
Persons Involved
Incident Summary
Activities
7:30 PM
8:30PM
9:30 PM
10:00PM
10:30PM
11:30 PM
Conclusion
Recommendations
Contacts
Appendix A: Email from Ph= ilippe to Apache reporting the bug and also submitting the fix for the bug.
7
The PM should be aware of the billi= ng stages of the project, as it is the duty of the PM to inform the accounts department on when to bill the client for the project.
Once the bill has been sent to the = clients for action, the PM should follow up with the clients to make sure that they make the payment promptly and on time.
8 Mana= gement of Clients and Third Parties
8.1 Cl= ient Management
Client management is one of the most important tasks for a Project Manager.&nbs= p; If the client is happy, the project will go on smoothly. As clients are human, you will need people skills to be able to manage them.&n= bsp; As people skill is something that you need to learn as you go, this document will not be able to teach you everything about client management.<= /span>
Learning from experience is the bes= t way to improve yourself in people skills and client management. However, this document will try to= give you as much head start as it possible can.
8.1.1 = What To Do & What Not To Do (Especially with new clients)
- Be punctual. If you cannot be punctual ALWAYS call the cl= ient well ahead of time to advise him of how late you will be and make sure that you arrive ON TIME.
- If you are not late, be pleasant, but NOT over enthusiast= ic. You should be warm, friendly and approachable, but not effusive.
- If you are late, apologise sincerely. Sincerity CAN be detected. If you are too stressed out about being late, DON’T sh= ow it. This is because you must exude the demeanour of a professional and= not a slave who hasn’t got his act together. As being late is a HUGE setback, you MUST come across as being thoroughly organised and calm WITHOUT FAIL.
- Ask for a complete brief and let the client do the talkin= g. Some clients may require a little prodding, but avoid this if possible unless the client is someone incapable of giving a decent brief. Take copious notes during the briefing. When the briefing has ended:=
- Quickly recap the brief.
- Ask every conceivable question you can think of – pre-empt every situation, all the time, bearing in mind the possible workload back in the office. If you think that time may be a problem, = DO NOT say “no” to the client right away. Instead, “warn” the client that the timeframe may not be possible because of ongoing work. Tell him that you need to go back to the offi= ce to double check on this and you will get back to him right away.
- After all your questions have been asked, recap everythin= g one more time – in order of discussion, please. Never mind if the cl= ient may seem a little impatient about this. Tell the client that you are d= oing this because you just want to be sure that you get everything right (a= nd say so nicely). After recapping all the points, GET the client to AGRE= E or confirm that everything is correct.
- There will be times when a client seems impatient, brusqu= e, or unwilling to listen to what you are saying. Often, they will often try= to take over the conversation or put words in your mouth. In such cases, = DO NOT let the client ‘win’ if you can help it. At this point, make sure you have eye contact and be bold enough to HOLD the client's gaze. Make him SEE that you MEAN business. MODERATE your voice through= out – SLOW DOWN your speech; lower your voice and even the tilt of your head. But make sure that your voice is calm, collected, professional AND pleasant. There is no need to be antagonistic or desperate. Above all,= DO NOT show any impatience or urgency to leave.
- At times, a client may seem reluctant to commit himself o= ver something that’s said. If these is the case, study him and try to figure out why – is he afraid of some higher authority? Is he af= raid that by agreeing, he will be putting his head on the chopping block? I= s he afraid that he might not get cooperation from certain parties? Probe discreetly if necessary and try your best to address his concern ̵= 1; even offer to help him by organising discussions, sending meeting minu= tes, etc. to the other parties he’s thinking about. Show him that you= are willing to champion his cause. Some may panic or try to dissuade you if/when you make such suggestions. In such cases, don’t be too easily dissauded. Gently, but firmly reassure your client that it is no trouble for you to go that extra mile. If still persists, then give in – on this occasion. Gently keep up the ‘pressure’ at other meetings – one day he will either give in, or he will show= you some sign that he feels ‘safe’ with you. Once the client f= eels ‘safe’, he will be easier to manage. Please note that you should NEVER give him the impression that you will bend over backwards= for him. If you do so, you will be trapped one day, and our whole company = will suffer simply because you have taught him how to TAKE YOU FOR GRANTED.= You are NOT a slave! You are a PROFESSIONAL and a concerned business associate. You MUST ALWAYS maintain this posture and attitude.<= /li>
- At the close of every meeting, try to get a little ‘personal’ with the client – chat pleasantly and ask about something that is close to the client’s heart, e.g. a hobb= y, a child, etc. If you don’t know anything, ask – find out. Sp= end a few minutes to show him that you’re a nice, caring person, although there is NO NEED to overdo the friendly show. Keep it short a= nd sweet, and smile pleasantly. Again, be sincere. Even the nastiest clie= nt has a soft side somewhere. This is an important tactic because it will condition the client to look forward to having meetings with you. Also= , by being friendly and concerned, you won’t have to play the entertaining game more than is necessary. Breakfast/lunch/dinner/other ‘treats’ should never be done too often because the client= can grow to expect them from you. If the client seems wary about telling y= ou about himself at first, you can get him to open up eventually by telli= ng him a little about yourself. By doing so, you’re showing him that you have nothing to hide, you are not afraid of him or anyone, and that you are willing to make yourself more ‘vulnerable’ to him.=
- Upon returning to the office, armed with your notes, go a= round and talk to the parties involved and update them on the meeting. Face-to-face updates (or phone calls) followed by email notes work much better than just email. This way, everyone gets fair warning about any unforeseen circumstances, including you. After you have done this, THEN you start putting the meeting down on paper. After this, check off everything that you have written against your notes and make sure that everything is covered. BEFORE sending off the document, read through it one more time and try to pre-empt any possible queries so that you can have an immediate response from anyone.
- At the next meeting when you present the report, show how= it addresses every point that was discussed at the previous meeting. In o= ther words, recap one more time. Then, present the solution and point out h= ow the solution answers all the requirements.
- Even if timelines can be met way in advance, it is wise t= o NOT always deliver AHEAD of time. Hold back at times and deliver the proje= ct only on the dot. By delivering ahead of time too often, you will again be encouraging the client to take it for granted that you are able to del= iver within very short timeframes. He will start to squeeze you for shorter= and shorter delivery times. One day, you will not be able to deliver, and = then you won’t look good.
8.1.2 = Tips & Things To Keep in Mind
- In whatever you do and say, try to be mindful that you won’t end up spoiling the client in the long run. What you are aiming for is mutual respect from the client – you won’t g= et any respect from a spoilt client.
- Always study and watch the client. Is his body posture or= eyes giving him away? Is he not telling you something that you should know? What is his personality like? How can you win his trust and respect? I= s he saying something but meaning another?
- Never be too quick to take what a client says about somet= hing or a situation at face value. Try to look beyond the words.
- Try to be on your toes and pre-empt situations. Try to re= ad your client’s mind.
- Try to put yourself in your client’s shoes and mind= set and ask yourself, what would cause you to behave like him? What kind of stimuli would he respond to? (Don’t be surprised, but some clien= ts like to be challenged, or even be given a ‘tough’ time. Th= is is because they want to see if you have the courage not to ‘fight’ with him, but to stand up for yourself and what you believe in.)
- Smile. Be warm. Be sincere.
- Avoid saying an outright “no” too quickly unl= ess it is absolutely necessary or if you can sense that he is open to accepti= ng it. Try to buy yourself a little time by saying that you need to check certain things first, BUT warn the client that you’re not too optimistic about being able to give him what he wants because of whate= ver reason. Tell him you’ll try, but that you can’t promise. T= hen when you have to say “no”, explain to him how hard you have tried.
- Always ask for clarification if you are not sure about wh= at you have discussed. Even if you have to make your client explain things 3 times over, DO IT. If you don’t, it can result in a costly mista= ke.
- If you detect a lack of communication within your client’s company, offer to help him keep the other parties infor= med or try to find a way to help him close that gap. Poor communication of= ten results in problems later down the road.
9 Docu= mentation of Events
10 Var= iations and Additions
10.1 V= ariations
During the course of the whole proj= ect there will always be variations introduced to the project. Variations are changes to the spec= s that the client requested to be included into the project. Usually these items will add time = and cost to the project thus it need to be documented the amount of extra time = and extra cost that will incur as a result of this new change.
Usually these items are imperative = to the project, i.e. it is a “must-have” else the application will not work. As such, we need to doc= ument the extra time and cost. Some= times the_company will absorb the cost for the variation but even if the_company is absorbing= the cost, it need to be made known to the client that the_company is absorbing = the cost. This is so that the kno= w we are doing them a favour and if they later complain that the project is dela= yed, we can argue that there were variations that caused them.
Sometimes variations can be a barga= ining tool for the_company’s sales team to get another job from the client. The sales team or eve= n you as the project manager can let the client know that the_company will do the variations for free but the client must agree to give the_company another project in the future.
The variations can be documented us= ing the Variations/Additions table below.
10.2 A= dditions
Similar to variations, additions wi= ll add time and cost to the project. However, additions are defined as items that the client requested to= be included into the project that were not initially speced out.
These items need to be documented b= ecause of the reason as stated above. The additions can be documented using the Variations/Additions table below.
10.3 E= xample of a Variations/Additions table
Description
A/V*
Request Date
Additional Time
Additional Fee
Notes
1
AAA and BBB were up in Country2 gathering specs for all the additional works that has yet to be confirmed by COMPAN= Y999 to work on.
A
8/10/2001 till 9/10/2001
4 man days
Absorbed by the_company
As the list of Variations/Additions= keep gets added as the project goes on, it is important you mark each new item in the list to differentiate them from the old ones. You need to update the list and se= nd a copy of the variation to the client every week. Mark the new items with the
icon. It would also help to use a differ=
ent
colour. Blue is the preferred colour to=
highlight
this, as it does not alarm the client like red do.=
= Item in the table should be sorted with the latest item first.
=
10.4 H= andling Additions and Variations
When dealing with additional works = (a/w), our intent is not to be so harsh that we offend the client. We don't want to say that EVERY additional item (even if it takes 30 minutes to implement ad does not affect overall timelines) is chargeable.
At the same time, we cannot be law either. We don't want to acce= pt an a/w that will extend the timeline, reduce our profit margin on the project,= or cause us to have resource clashes on other projects.
Dealing with A/W is hard.
Try to work as a team with your cli= ent-side PM. Help him or her understand your limitations. You "can" do A/W sometim= es for free. We are not opposed to t= his, even if it extends the timeline, reduces profit margin, or causes resource clash.
What we cannot do is implement so m= any A/W that the project fails.
Keeping specs to a level that makes economic sense for "both" parties will assure a successful projec= t. If they increase the project scope so big that we can no longer afford to finish it, it will be bad for both sides.
Consider a one-month project with o= ne developer charged at 2K SGD/day. Suppose that you as a PM also spend 1/2 your time on it at 2K per day. If so, we would charge a= bout 60K SGD for the project. Now suppose that the cost on our side for the project is 30K SGD (which is prob= ably pretty close to the truth). I= n that case, our profit is 30K SGD.
Now suppose your project is extende= d to 2 months with no payment for A/W. If this is the case, the total project revenue remains 60K SGD, but the cost increases to 60K SGD. In this= case, we make ZERO profit on the project.
Worse still, if we had completed the project on time, we could have devoted the resources to another month-long project. If we had done that = we would have made a profit of 30,000SGD on "both" projects.<= /p>
In other words, the cost of the pro= ject is not just a ZERO profit. It is= also a 60,000SGD loss in opportunity costs!
the_company will quickly go bankrup= t with projects like this.
"Affording" a project is = not just about cash flow though. It is also about resources. If you go over time on your projec= t you may lose your resources to another project, and then how will you be able to finish it. If you put so many burdens on your developers that they burn out after many nights and weekends of work, the project is in trouble.
In the end, if you manage a/w wrong= , the customer will end up getting only half a product or a complete one with lot= s of bugs and problems.
Try to express yourself that way. T= he reason we are so concerned about A/W is also cause we are looking out for t= heir best interest. They know that= we are a hard working company. W= e are not trying to screw them.
It is not a black and white issue. = You cannot go from totally lax to totally anal. You need to strike a balance in the middle and always keep the end goal in mind.
We want to produce the best solution possible for the customer. Do= ing so involves so much more than technology (the "best" solution is NOT= the "technically" best solution).&nb= sp; It involves the_company's cash flow, the customer’s cash flow, people issues, timing issues (marketing etc), and so much more. Your job is to understand and comm= unicate the complexities to the client-side so that together you can make good and "fair" decisions about scope.
11 Fil= e naming standards
One of the most important task as a= Project Manager is to do documentation of the project as the project progress. This includes getting confirmation= from all parties documented, either in email or any other format. This documentation is done via sav= ing emails, documents from clients, documents from 3rd parties, etc.= on to the network folder.
In order for others in the project = team to understand what you saved on to the network you need to follow the file nam= ing standards that everyone at the_company can understand.
Rule 1: All file names must be in l= ower case.
Rule 2: They must have a date. The date needs not be the date tha= t you safe the file. It should be t= he date that corresponds to the documentation. E.g. if the document is for a meet= ing minute for a meeting held on 12 Dec 2001 but the minutes was only prepared = on the 15 Dec 2001, the file name should bare the 12 Dec 2001 date.
Basically there are 2 types of documentation:
11.1 C= orrespondence
For all correspondence documentatio= n, which includes email, minutes, etc., you should save the file using the following format:
yyyymmdd_<filename>.<filetype>
E.g.
20011219_Product9_issues.txt
11.2 O= ther Documents
For all other documents such as Requirements Specifications, Technical Documentation, etc. the file name sh= ould follow the following format:
<filename>_yyyymmdd.<filetype>
E.g.
gmfc_phase3_20011225.doc
12 Tra= vel Arrangements
Sometime, a project can be from overseas. This would mean tha= t your team and you would need to travel to the client’s office (outside of = Country1) for meetings, testing and other project related activities.
As the Project Manager you are in-c= harge of making travel arrangement for your team members. You need to arrange these with the Office Manger, CCC. She takes= care of all the travel arrangements.
To book a flight for your team memb= er, you will need to let CCC know:
- Passenger name
- Flight schedule (When leaving and when coming back)
- Ticket number, if applicable
After you have booked the flight, y= ou need to make sure that your team members have accommodation if they have to stay over night. You need to make arrangement with Rita for this too.
Here are some important telephone n= umbers for projects in
Country1 Airlines (SQ):
- Country1 Office – 62238888
- KL Office – 26923122
Country2 Airlines (MH):
- Country1 Office – 3366777
- KL Office – 7493000
- KL Office – 1300-883000
Crown Regency Serviced Apartment:
- Address: 12 Jalan P. Ramlee,
- Tel: 603-21623888
- Fax: 603-21644673
13 Syn= cing your laptop for Offline Network and Email
There are currently 3 the_company l= oan laptop your team can use when they are travelling. However, as the project manager, y= ou will have priority to the laptop. Therefore it is important that you prepare the laptop before travell= ing to make sure that you have all the necessary documents and email set up when you are offline from the the_company Intranet and network.
13.1 M= aking the network available offline
When travelling with your laptop, i= t is always nice to be able access your project folders as if you are still on t= he network. On Windows 2000 and = XP, there is a function called “Make Available Offline” that will a= llow you to do that.
To make a network folder available = offline, go to the network folder and right click.&= nbsp; On the right click menu, choose “Make Available Offline”= and the sync wizard will show. Fo= llow through the wizard and you should have the selected network folder synced f= or offline work.
This feature will allow you to make= changes to the network folder offline and when you are back in the network, all new files that you added to the network will be added automatically to the network. It will not delete a= ny network files even if you deleted it when you were offline. It will only add files and not del= ete any without prompting for your action.
Once you have made a network folder offline, you can access it via the Network Neighbourhood as if you are on t= he network.
13.2 H= ow to access the the_company Intranet remotely
When you are on the road, it would = be nice to be able to access the the_company office Intranet, namely the calendar a= nd the address book.
To access the the_company office In= tranet, you will need 2 things:
- Internet access
- SecureCRT (Can be found in //bacchus/installers)
You need to connect to mbox.the_com= pany.com with SecureCRT.
On the SecureCRT menu, click on "Options", then "Session Options". Click on "Port Forwarding&quo= t;.
Click to "Add" a port for= warding.
The options are "Name". "Port", "Remote Host".
- Name: the_company Intranet
- Port: 80
- Hostname: mbox.the_company.com
After you have all the above set up= , go to your browser and then type in http://lo= calhost/office to access the menu for the the_company Intranet. From here you should feel as if yo= u are accessing it from the office network, except for the speed difference.
13.3 H= ow to access to your email remotely
There are several ways to read your= email when you are not in the office.
13.3.1 Use pine as the email client
This is a simple way of reading your email. Use SecureCRT or Putty= to access to mbox.the_company.com. Once you have logged in using your username and password, type pine = on the command prompt.
The Pine application should start a= sking you to login to your mailboxes.
13.3.2 Use a MS Windows GUI email client
There are many email clients that y= ou can use to check your email as long as they support POP3 email protocol. However the_company only recommends either Eudora or MS Outlook.
To sync your email to your laptop, = copy the whole program folder files on to the laptop and run the application from the laptop.
To check your email, you need to po= int your email server to mbox.the_company.com. This is to check for incoming email.
To send email, you will need a SMTP server. When travelling, get = the SMTP server information from the local ISP that you are using.
In KL, the ISP is TimeNet so the SM= TP server to use is smtp.time.net.my.
When you come back to the office, m= ake sure that you copy the email program folder back to your desktop PC before check= ing your email.
If you prefer you can use IMAP email protocol. For more informatio= n on how to use IMAP, please refer to the_company’s resident system administrator.
13.4 H= ow to access files on Bacchus that were not synced to work offline
There will be times when you need t= o access a certain file that is on Bacchus but you did not make it “Available Offline”. You can still access files on the Bacchus server using putty and pscp (Installation file = can be found in //bacchus/installers).
To access files on Bacchus which is= not synced as offline files, do the following:
- Connect to mbox.the_company.com using putty or SecureCRT.=
- Once logged in, type smbclient //bacchus/data
- You will be prompted for login information for the Bacchus server.
- After you have logged in, you will be on //bacchus/data.<= /span>
- The smbclient acts like an FTP client so to navigate thro= ugh the files, you will need to use FTP commands like get, etc. Type HELP for more informatio= n.
- Once you have found the file that you want, type get <filename>.
- The file will be copied to your home directory on mbox.th= e_company.com (which is also the LINUX server).
- Once the file is on your mbox.the_company.com server, go = to pscp application via the windows command prompt and issue the following command:
pscp <username>@mbox.the_company.com:<filename> .
E.g.
you@m= box.the_company.com:PM_SOP.doc .
· The file will be downloaded onto your pscp directory.
13.5 H= ow to setup dialup Internet access in Country2
There are a few ISP in Country2 tha= t you can use but there is only one that provides free Internet access, TimeNet.<= /span>
Here is how you can setup your lapt= op for dialup Internet access when in Country2:
- Make a new connection with all default protocol.
- The ISP number to dial: 27171517
- Username: the_company
- Password: ZZZ
You can also use the_company2, the_= company3 and the_company4 as usernames to logon to the ISP. The URL for TimeNet is http://www.time.net.my.
13.6 H= ow to retrieve voice mail when roaming in other country
13.6.1 Singtel GSM
For GSM subscribers, simply make an international call back to Country1 to access your mailbox by dialing +65 9= 630 1389. When in Country2, dial 02 9630 1389. Please also key in your PIN and mobile phone number. <= /p>
13.6.2 Singtel GSM 1800
For GSM 1800 subscribers, simply ma= ke an international call back to Country1 to access your mailbox by dialing +65 9= 640 1380. When in Country2, dial 02 9640 1380. Please also key in your PIN and mobile phone number.
13.6.3 Starhub
· Dial +65-9-850-1303 (02-9850-1303 from Country2).
· When the Voice Mail Syste= m asks for your mailbox number, key in your StarHub number.
· Key in your password when prompted.
· You may now access your v= oice messages.
13.6.4 M1
- Dial +65 9680 1381 (02-9680-1381 from Country2) from your mobile phone or any fixed line telephone.
- Enter your mailbox number, which is your mobile phone num= ber
- Enter your password
- You have now entered your VoiceMail box. You can follow t= he voice prompts to utilise the various mailbox features
[1]