project manager

Ten Commandants for Project Manager in Requirements Change Management

Requirements Change management if managed haphazardly may become a disaster for both customer and the product, so it has to be managed very wisely and tactically. And the role of a project manager in this is very crucial.

In such a case the role of Project Manager can be sequentially summarized as below:
10. He has to understand well the total requirements of the customer
9. He has to map these requirements in the software already catering to other customers
8. This way he will be able to find out and check what is the impact of these requirements on the software?
7. He also has to check out if some practices already built in the software are better than what the customer is asking for?
6. He has to revert back to customer to discuss (and rather educate him) the benefits of adopting the practices already built in over the changes asked for
5. Customer might agree to some, and might still ask for the changes at certain places
4. Now the project manager has to sit with his product manager to convince him to incorporate these changes
3. Understand the impact of these changes and get back to customer if there is any adverse effect
2. Finally get those changes incorporated in the software
1. But don’t assume that the story is over…

Project Manager – A Solid Bridge between Customer and Product Manager

Let us talk about existing software required to be implemented at a new geographical location. Definitely because of a different location there will be certain new requirements plus some changes here and there in the existing built to meet customer specifications. This need to be handled very minutely and tactfully in such a manner that on one hand it meets all customer requirements and on the other hand puts least burden on the team and software in terms of catering to those specifications or changes asked by the customer.

How it needs to be managed, monitored and done is an art that requires certain level of high skills in the project manager who has to act as a solid bridge between the customer and the product manager. If we consider Project Manager, Customer and Product Manager as three different islands – it is the Project Manager who has to synchronize and gel well together all the three different islands in the journey of building or moulding the software to meet all the requirements of the customer. The project manager in this case is the center point with Customer and Product Manager on his two sides.

How Requirements evolve during a Software Project?

New requirements or change in existing requirements is an inevitable process in any software project. As a project manager you encounter it during every phase of a project. Some requirements emerge internally by your own team and some come from the customer.

Internal requirements result from clarifications in customer’s existing requirements and enhancement of project team in business knowledge. Your team evolves better ways to manage customer’s existing and forthcoming requirements in a better way thereby seeking a change in existing code. It could be a major change asking for involvement of considerable number of developers for certain mandays. Or it could be a minor change involving just a couple of hours.

On the other hand, another scenario of change in requirements could be when your team of developers is working on building the customer requirements in the new or existing software and you receive a change note from customer requiring a major or minor change in the software.

Project Scope – Customer needs to be shown the right path

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.

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

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.

20 gems for project managers

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

What sort of driver are you?

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.

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

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.

Why is Change opposed?

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.

10 innovative ways to become a “lousy” 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.