project manager

Oct 30 2009   10:00AM GMT

Project Scope – Customer needs to be shown the right path

Posted by: Jaideep
Project Management, project scope, change management, project manager, software, Project, Software Project, project implementation, sign-off

One of the project managers of an ERP implementation company got himself into a tight corner. He found himself in a tough situation where an already ‘mutually sealed’ project scope asked for one or two new requirements (or changes in the existing functionality) from the client everyday while implementation. The broadly agreed upon requirements within the earmarked project modules came out with some changes here and there, some new add-ons. Customer is not ready to accept ‘no’ to any of the requirement since they have a mindset that they have ordered for a big project and are investing a large amount of money in it. The customer keeps on pushing for all their ‘now invented’ requirements to be mapped in the existing ‘project scope’. This seems to be a never ending story. The project manager is tightlipped to start a new module since the running one is not ‘done’ so far. And he also can’t say NO and mark any requirement as ‘out of scope’ since he does not want to annoy the customer and wants the project to be a success.

What should be done in this sort of scenario?

The project manager privately updated me about the situation and asked for my help to get him out of this situation. I told him if he carries out in the way he is – he will never be able to finish his project.

I advised him to have an emergency meeting with his client and share his pain with them. Make them clear that you are not saying No to their requirements but there is a need of a boundary line drawn with mutual understanding. Cater to so far documented requirements as phase I. Finish it off. Get it signed off. Whatever new requirement or changes come from the customer – document it, analyze it. Any requirement that is asking for more than 4 hours of efforts, put it in phase II of the project. As soon as you finish off the phase I, finish off Phase II, sign off. And so on.

Oct 16 2009   10:00AM GMT

Five Tips for a project manager for driving (and completing) a Project successfully

Posted by: Jaideep
project manager, Project Management, Software Project, project team, software, Project

Involve all stakeholders throughout: This does not mean that all people involved in the project have to keep them available full-time during the project but it means that the knowledge about the project, project progress, shortcomings, bottlenecks etc. should be continuously shared across the board universally. All members should have the same set of information available with them at any moment of time. Involvement will definitely vary from person to person and phase to phase.

Collaborative, Participative, and Interactive: The information flow should not be one way. It should comprise of praises, shouts, appreciations, arguments etc. Let each brain contribute in making it a success.

Be Demonstrative: Lead the project. Demonstrate by actions what you want from other members. Use fewer words and more actions, especially in case of crisis or a problem.

Identify the lazy goat: If there is any lazy goat that is bound to spoil the show, indentify it at an earlier stage so as to avoid higher risk at a later stage.

Keep a set of your customer shoes with you: Borrow a set of your customer shoes, and keep it with you during the project. Put off your shoes frequently, wear your customer shoes and then have a look at the project pace, progress and status. It will definitely give you a different perspective view.

Oct 14 2009   10:00AM GMT

20 gems for project managers

Posted by: Jaideep
Software Project, project manager, tester, quality control, testing, software, quality, Development, developer, coding, coder, programmer, programming, technical knowledge, Bug, bug report

1. A project manager is always right
2. Quality is seriously maintained by developers while developing software
3. A separate set of people (quality control or testers) is not required to take care of the software produced or developed
4. Testers don’t do any substantial value addition in product development
5. Testers lack business knowledge
6. Testers lack technical knowledge
7. Testers lack essential skills to test software
8. Testers don’t understand product requirements well
9. All developments and implementations are prone to extensions because of change in customer requirements or other customer constraints
10. All delays in development and implementation are due to customer
11. Testers have a very little role to play in product development
12. Testers need less than 1% of project time for testing and reporting bugs
13. Testers should be able to test the product well even if substantial knowledge related to product has not been shared with them
14. Testers are the biggest misleading agents
15. Developers and programmers are not testers and thus are not supposed to test what they develop
16. Testers are de-motivators to programmers and developers
17. Testers are project delayers
18. Customers blame development and implementation teams just to hide their own shortcomings
19. Customers don’t know to explain their processes and business rules well
20. Customers are always interested in delaying the project

Oct 9 2009   1:17PM GMT

What sort of driver are you?

Posted by: Jaideep
Software Project, software delivery, Project Management, project manager, Project Development, project implementation, project stage, customer requirement, quality, product quality, software quality

I have seen different type of drivers on road: some drive very fast violating all rules and regulations to reach the destination. Can this attitude work in software development and delivery? I don’t think so, if the project manager is more worried about reaching the implementation stage without bothering about the customer requirements, probably he is calling for a big bunch of troubles.

Another set of drivers are overcautious type. They will take lot of time in building customer requirements and will be uncompromising towards quality of product to such an extent that every deadline will be crossed without meeting it. Can such project managers be liked by customers? Or by the management?

Our next category of drivers is ‘stick to the route’ kind. They will never change the route whatsoever is the hurdle is and whatsoever is the impact on the delivery. Can customer accept a project manager who is damn fussy about the requirements?

Some drivers believe in ‘change with the wind’ style. They start for a destination, get a call on the way from the customer to divert to another destination, and the driver agrees happily. Probably this is the quality that customer wants in the project manager these days.

Sep 23 2009   10:00AM GMT

Quality of documents says it all about the health of the project

Posted by: Jaideep
Project Management, project manager, Software Project, business analyst, coder, programmer, tester, quality

A software project has to undergo various stages before reaching the final stage of customer sign off. At each stage of the project there are certain set of documents that are maintained by the project team for internal or external purposes.

These documents are prepared by various team members – by business analysts, by coders, by project manager, by testers and by other managers.

The Quality and maturity of documents straightaway tell about the health of the project, the team, the management, the product and the progress. It tells clearly about the intentions behind the documentation – that if it is merely a formality or it is really meant for helping the project progress.

And it is not difficult to ascertain the intentions after going through the documents maintained or being maintained during the project.

Sep 22 2009   10:00AM GMT

Why is Change opposed?

Posted by: Jaideep
change management, tester, programmer, coder, project manager, Project Management

A coder or programmer when told that he is not writing his code, by way of presenting him with a list of bugs, he is being told to CHANGE.

A tester when is told by his superior that he lacks business depth for testing the product, he is being told to CHANGE.

A project manger when told that he has to improve his way of managing a project, he is being told that the current methodology does not suffice the purpose. It requires a CHANGE.

A management when consistently fails to deliver its commitments to its employees and customers, means it needs to introspect and CHANGE.

When a person, department, team or country stops delivering, or starts giving indications of failure in one aspect of other, it asks for CHANGE.

Change is powerful.
Change is inevitable.
Change does not challenge your knowledge.
Change does not indicate that you are incapable. Rather when one is being told to change, someone has confidence in his capability to CHANGE and PERFORM better.
Change does not mean that you are wrong, it means that there is a scope of improvement.

But

Change is often opposed as a natural tendency because it is taken as an indication that you are not performing well and what you are doing is not doing well.

Sep 11 2009   10:00AM GMT

10 innovative ways to become a “lousy” project manager

Posted by: Jaideep
Project Management, project manager

Project Management is not simple. It requires lot of skills (and learning and experience) to become a good project manager. A good project manager is the one who plans and executes well – all the stages of a project. Finally if project finishes in time with a SMILE ON CUSTOMER FACE, the project can be treated as successful. It is the option of a project manager to label himself as “lousy” project manager or “successful project manager” depending on how he/she manages the show throughout.

To become a “lousy” project manager, following steps can be followed which are quite simple in nature and easily adoptable. Vice versa of these steps can help you in becoming a “successful” project manager, but following that will require some smart efforts and a “fire in the belly”.

The steps are:
10. Don’t own the project: You can easily pass on the buck to anyone engaged in the project. Keep yourself focused on the minutest of the failures and find out the right guy to be blamed for it. With smart reasoning you can easily convince the management and other stakeholders about the failure, its reasons and justification for delays in the project.

9. Assure insufficient customer requirement gathering: To achieve your target, ensure that the customer requirements are not gathered in the proper fashion. Ask irrelevant questions to customer and that to the irrelevant persons for gathering customer requirements. This will surely give you a good reason to convince customer later that it is because of their fault in specifying proper requirements that the product built in not meeting their requirements and you will have another stack of ‘months’ in your kitty to linger on the project.

8. Build a thick wall: Between your management and customer, build a thick wall so that all communication never gets transparent. This will help you in moulding the things in your way as and when required. Similarly build a thick wall between various sub-teams in your project like testers and developers, developers and implementers etc.

7. Build inappropriate teams: For managing your different phases of project, inject inadequate number of persons in your various teams responsible for different phases of the project. Also ensure that that most of the team members are “dumb” enough in knowledge and smartness so that you can easily place the “failure” hat on anyone’s head at any rough moment of the project.

6. Ambiguous documentation: Ensure that the documentation is not at all crisp clear at any phase of the project. Let it be as ambiguous as possible, but in a smarter way, so that nobody is able to figure out the objectionable part.

5. Stay unfocused: Find out some other critical issues not related to project but that can easily make you reasonably justified for not able to devote proper time on the management of project.

4. No Reporting: Let each member enjoy. Make no provision of timely reporting about the progress of project.

3. Dearth of technical knowledge: Don’t develop your technical knowledge required for your project. Let your technical people befooling you in their own way. Ignorance is always bliss.

2. Be Political: Keep on taking your customer on a different track by telling them wrong stories about your management and product in process. Also keep informing your management about customer’s lack of knowledge, involvement, providing of sufficient key users etc. that will become your strong ammunition for shielding you.

1. Repeat everyday: All points above have to be read repeatedly everyday so that you end in becoming a “perfect loser” at the end of the day.

Sep 7 2009   11:00AM GMT

Top 5 reasons of Project Manager getting fired

Posted by: Jaideep
Software Project, project manager, Project Management, business knowledge, project team, team member, software product, product meeting, project meeting, customer meeting, technical depth, technical knowledge, project feedback, team feedback, customer feedback, project failure

Project Failure: First failure will downgrade the level of next project to be given to the project manager. Not only this, but it will also trigger hidden cameras in the organization that start monitoring each and every step of project manager. These hidden cameras could be top management or some selected down the line people working with project manager.
Customer Feedback: Organizations are taking customer feedback very seriously. A remark by a customer regarding a project manager – “I want this project manager to manager all my future projects ordered to you. Infact if you don’t depute this person as project manager, you don’t accept our orders” triggered such a magic that it immediately presented the project manager with an out-of-turn hefty increment. On the other hand a customer CEO sent a confidential email message to the CEO of projects organization stating – “We don’t want the current project manager to be seen in out campus with immediate effect” put a very big question mark on project manager’s capabilities.
Project Team Feedback: Sometimes even if Project fails project manager is able to survive if project team and customer give a positive feedback. Then the reasons are different which are beyond the control of project manager. But if project fails and feedback is also not very positive, all axes will fall on project manager’s neck.
Lack of Technical Depth: A shallow or artificial demonstration of technical depth will not help for long. Although project manager has not to do technical activities on his own but his depth of knowledge will definitely help in driving the project in right direction and meeting targets.
Lack of business knowledge: Sometimes smart team members manage many a weaknesses of their project manager if he has demonstrated his strength in certain areas. But the lack of business knowledge is something that will certainly affect the product built, customer confidence in product and project manager’s knowledge. And if project manager is not clear about the business concepts of the customer, his presence in project, product and customer meetings will not be as effective as it is supposed to be.

Aug 14 2009   10:00AM GMT

Six indicators for a project manager - of their downfall (or failure) in project management

Posted by: Jaideep
Software Project, Project Management, reliability, quality, software quality, testing, Bug, project manager

If you, as a project manager, are fond of thunderstorms, volcano eruptions, etc. it is ok howsoever you drive a project. Otherwise look below at six indicators mentioned below. Even if one of the reason prevails in your project’s lifecycle, manage it, get rid of it, immediately, before a small wound becomes a big septic.

Irregular releases – when plan or commitment varies from actual delivery inconsistently. Some plans finish in time, some with small variation and some with huge variation. It means there may be a volcanic surprise.

Drop in quality or inconsistent quality of product built: Testing is happening, bugs are being reported but if the product coverage is incomplete while testing, or volume of low quality bugs reported is higher as compared to some severe bugs skipped in reporting, there is a mishap going to happen for sure.

Wrong cycle time estimations: if your estimations are going haywired, you plan milestones and achieving them itself if becomes a project, and go beyond control for achievement – there is a mess, in a big way.

Unplanned expenditure like overheads, delays: all these estimates going wrong, will call for extra time for team members and extrapolation of deadlines – a clear indication of a thunderstorm coming on the way.

Predictability: if your team members lose their commitment level, your predictability will become a big question mark for your management and for the customer.

Reliability: your team members’ reliability will invariably start decreasing the moment all this starts happening – and so will be yours.

Jul 17 2009   10:00AM GMT

Why hit the people? Hit the process if there is a failure in a software project

Posted by: Jaideep
Quality Assurance, Software Project, Project Management, people management, HR, QA, QC, Q-tag, developer, quality, quality control, quality culture, quality building, product, stakeholder, business analyst, project manager, project team, development team, testing team, implementation team, product build

People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.

Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:

Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.