This is the first article among the series of articles that I intend to post for effective Project Management in the field of IT. While these concepts are mainly based on my IT experiences, I am sure a lot of them can be applied in other verticals as well. At Walking Tree – we believe in sharing and empowering. If you have any suggestion or comments you can post it on this article or contact us directly.
I know that thousands of people have talked about Project Management. Still I see that Project Management is a challenge in every company. If a Project succeeds then people feel happy about it and if it fails then things move on by finding few scapegoats.
Alright. Since Project Management is about Managing Projects. There are many questions that come to our mind
- What is a Project?
- Why do we have Projects?
- What is the background to this Project?
- What is expectation from Project Management?
- Why do projects fail?
- Who all are the stakeholders in the project?
- What are the deliverable involved during a project?
- How do I know whether I have defined the project (or deliverable) objectively or not?
- Etc.
What is Project?
A project is a temporary endeavour undertaken to accomplish a given purpose. It contains a set of activities with start date and end date and by the time it finishes we get some tangible result/product. We often categorize a work as a project if the activities
- involves more than two people or
- involves more than two weeks of effort or
- requires more than one month of elapsed time or
- involves substantial risks or
- has severe impact on its success / failure or
- falls outside the normal operations
If we have any of the above criteria true for a given activity then it is a candidate for becoming a project.
Why do we have Projects?
There is only a few reasons to have a meaningful project.
- It will save or generate more money than we intend to spend on it (ROI?)
- We have to do it in order to comply with certain standards/rules (Cost of doing business?)
I don’t see any other reason. Hence, it must always be clear that whenever we are doing – we must know the dollar value that we want to generate/save out of that project. If you are not able to find $$ value then there is some gap which needs to be filled-in quickly.
Many times definition is so abstract that it is extremely difficult to derive $$ values. This is where you can use following questions to bring in the required objectivity:
- So what?
- How much? and
- What does work out to in dollars?
Remember – if you cannot get the customer to think in terms of dollar value, be assured that most of the involved stakeholders have less clarity and Project will run with a lot of risks.
What is the background to this Project?
Before a project manager gets involved in a project, often there is enough momentum and history created behind the project. While sometimes it may be helpful to join the project with a fresh mind, often it will help to know the background.
You must try to understand
- Business condition which might have prompted someone to come up with a project
- How the project was presented to management, how it was evaluated and approved by management
- What all alternatives were considered before deciding on this project
- What were the arguments against the project
- What is the visibility of the project to the client company
- What is the attitude towards the project
Once you understand that – you get enough idea about where you see potential risk and accordingly you can focus in that area to cut down the risks as early as possible. Many times you get conflicting background information from various sources. In case of conflicting information, it becomes important to ask generic questions and make your own observations.
What is expectation from Project Management?
The simple expectation from project management or any project manager is to
- Understand the project
- Define the project
- Plan for the project execution and
- Execute the project
Although, above steps are mentioned sequentially, there will be iterations at times. However, if above four are achieved then effective project management can provide
- Better control of financial, physical, and human resources
- Improved customer relations
- Shorter development cycle (better time-to-market)
- Lower costs
- Higher quality and increased reliability
- Better internal coordination and
- Higher worker morale
Well, if you are not able to achieve any of them and few other wish list that you may have then there is some gap in your Project Management.
Why do projects fail?
First of all – let’s define what is the failure in this context. In my perspective – failure is anything which doesn’t meet an initial commitment. I understand that initially there is a lack of clarity and over a period things evolve. However, it is the responsibility of project management to keep on setting the correct expectation and ensure that the commitment statement also changes alongside and it gets communicated to the customer.
The commitment primarily includes following
- Scope – which is requirement / business need
- Schedule – time line
- Cost (budget)
- Process
While following agreed Process enhances overall success percentage and it provides confidence to the customer – it is important that any change in Scope should also lead to a review of schedule and cost. This is where Project Management seems to be struggling due to whatever reason. Scope changes many times and they fail to ensure that Cost and Schedule changes are also taken care. Remember – any imbalance in scope, cost and schedule will cause one or more stakeholder to be unhappy and this may lead to lower quality and eventually, it will take you towards failure.
Who all are the stakeholders in the project?
Many times we are not even aware of who all are the stakeholders in a given project. Well, if you document use cases – you know there are actors – and that may roughly translate into some of the stakeholders. However, the situation becomes really grim when it comes to the internal project. People don’t see any stakeholders. They stop seeing a need to evaluate budget as if our own resources has no cost associated with that. Many times the same set of people starts under performing. Hence, in any project – it is important to identify all the stakeholders, ensure that everyone is playing their role appropriately and effectively & manage communication across the stakeholders most effectively.
I see following key stakeholders categories:
- Client project management – which is sponsoring the project and responsible for approving any document. They often look for status report at agreed period or on demand.
- Other Management – the client management team which may not be directly involved – but they are interested in the success or failure of this project. Often communication happens through email and news letter.
- Client team – client staff directly involved in the project – specifically for the purpose of providing detail, examples and business requirements. Often team meeting, email and telephone conference is conducted for formal communication
- Users – client staffs who are not directly involved, but they will be using your solution / product. Often communication happens through internet website, email and training sessions etc.
- The project team – includes Development as well as Quality Assurance. Often team meeting, email and telephone is conducted for formal communication.
- Your own management – they often look for status reports.
- Operation & Support team – communication happens through the agreed support protocol (tier1, tier2, .. etc.)
- External Stakeholders – customers, suppliers, vendors, etc. Often communication is done with them through internet website, email, phone.
It is obvious that there are number of people involved in most of the project. Hence, it is important to define your communication plan as per the agreed scope. For example – if scope doesn’t include talking to External Stakeholders (which you may need to document in SoW) then you can delegate that responsibility to client Project Management team and put a clause to ensure that any dependency on supplier is really taken care by the client project management team. Remember – every action has a cost associated with it. Also, remember that ignoring any step is not at all a solution. So, someone has to take care of it.
What are the deliverable involved during a project?
While we have been talking about various aspects of project management, the most often talked aspect is Deliverable. Deliverable are the tangible things which you agree with the customer to deliver on the agreed date and with agreed quality level. This is what the customer gets in return of the payment that they make. Some of the deliverables may need approval from customer, some of them would be just for their information and some of them you may not even share with them. However, even if you don’t share a few deliverables with the customer, for the sake of transparency, it is often better to list them in some formal document. This will definitely provide more confidence to your customer. Most importantly, do what you document or communicate.
Here I have divided deliverable according to different Phases that we encounter during the development process
Pre-Sales
- Proposal
- Quotation
Planning Phase
- Project Plan
- Statement of Work (SoW)
- Cost Benefit Analysis
- Scope Definition (Requirement document)
- Work Plan
- Estimates
- Budget
- Schedule
- Overall approach and process document
- Etc.
Design Phase
- Business Rules
- Data Model
- Process Model
- Technology Recommendation
- Solution Approach
- User Interface Specification
- Impact Analysis
- Buy Vs Build Analysis
- Etc.
Acquisition Phase
- RFQ and its evaluation process
- Hardware capacity planning
- Maintenance plan
- Any recommendation
- Etc.
Development Phase
- Code
- Unit Test Cases
- Unit Test Plan
- Integration Test Cases
- Integration Test Plan
- Integration Test Results
- Solution Test Cases
- Solution Test Plan
- Solution Test Results
- System Test Cases
- System Test Plan
- System Test Results
- Application documents – including operation guides
Implementation Phase
- Implementation Plan
- Training plan
- Training material
- Operating procedure
- Cut over plan
- Handover plan
Well, above list of deliverable may be suitable in general. However, you may need to modify it based on exact customer needs. However, this will give you a very good list to get started. At least you can use this to ask customer if they need any of them.
How do I know whether I have defined the project objectively or not?
Well, there is no prize for guessing why we need to define projects very objectively in a documented format. Remember – unless all the stakeholders can derive same meaning out of the project definition, we will be inviting conflict at some stage of the project. We must have two things defined very objectively
- Project Objective and
- Project Scope
Project objective must be SMART. Let’s see what SMART means in this context:
- Must talk about Specific cause
- Must be Measurable
- Must be Achievable
- It must be Relevant
- It must be completed Timely
Once you have got SMART Project objective, you must make sure that Project Scope is also explicitly defined. Remember that scope changes are often the reason for project budget and schedule overrun. Make sure that everyone involved understand that there is nothing called obvious – if it is not documented in the scope (or BRS as we call it at Walking Tree). To client of course they will find that missing feature is obvious gap. However, unless that was documented in the agreed requirement, it is NOT a gap. If you want to save your company, team and yourself then make sure that client understands the concept of change of scope.
Not let’s get practical. Many times we will not have complete clarity before we get started on the project. The more time you spend on requirement the better clarity you will have. However, you will have to draw a line. Somewhere you will have to document unknown things as risk and move forward. Your estimates and planning must take care of such risks and handle them timely.
Some of the way to handle scope related issues are to have
- Appropriate scope finalization checklist
- Appropriate Scope Change process
- Well defined Change Control Board (CCB), which must review impact on project, schedule and cost
————————————————————————————————————————-
As part of this article – I have tried to give you a shallow insight about Project and Project Management. I have purposefully omitted some of the major topics from this discussion as they require their own context and details. I will cover the best practices that we follow or intend to follow at Walking Tree. This will hopefully be of some help to you to manage your project effectively.
Walking Tree is a process oriented company. We provide range of professional services apart from implementing our own products for the customers. We believe in process and we believe in ensuring that all the stakeholders involved in the project should be happy. You can reach us by visiting our contact us page.
