change management

Nov 13 2009   10:00AM GMT

Ten Commandants for Project Manager in Requirements Change Management

Posted by: Jaideep
software requirement, Project Management, Software Project, project manager, change management, product manager, software product

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…

Nov 11 2009   10:00AM GMT

Project Manager – A Solid Bridge between Customer and Product Manager

Posted by: Jaideep
project manager, Project Management, Software Project, product manager, customer requirement, change management

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.

Nov 9 2009   10:00AM GMT

How Requirements evolve during a Software Project?

Posted by: Jaideep
software requirement, change management, Software Project, Project Management, project manager, project phase, developer

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.

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 12 2009   10:00AM GMT

What customer type you are?

Posted by: Jaideep
software product, Software Project, customer requirement, business requirement, code, software, change management, software implementation

One customer type focuses on current requirement, rightly built, with more flexibility towards the business requirements built-in in the database rather than in the code. They believe that if the software meets their current requirements well, the future requirements will be built in at the need of the hour. The reason for this is that nobody at the moment is sure about the future requirements and when the change will be required. The change could be required one day after the current implementation or after five years. The changes required could be insignificant, small or not so much effort consuming.

Another type of customer is who is more worried about tomorrow without focusing more on the current built. The future requirements which are not too clear at the moment, are guessed by the customer and forced to be built in the product without really understanding if these requirements will ever be used, or if the requirements built are correct as per future needs as nobody can define them correctly at the moment.

Probably if requirement handling is managed more at database level than in the code, it gives more flexibility to the product.

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.

Jul 10 2009   10:00AM GMT

If you don’t change with the ‘Change’ you get [ex][change]d

Posted by: Jaideep
change management, Project Management, project timelines, Software Project, software build, test phase, testing, software, customer requirement, business requirement, product delay, product launch, project phase, development phase, software development, software testing

In my June 15 2009 post – “Do’s (+) and Don’ts (X) in Project Management”  http://itknowledgeexchange.techtarget.co…), I got a query and am posting it here as it is - As mentioned by you in one of your post “Single constant in business is Change”. But often software vendors are too bound by the requirement documents that they fail to gauge the change in the underlying business need that they are trying to cater to. I understand that there are time and cost considerations, but many a times the attitude is not conducive. Could you throw some light on this in your writings…?

First of all let us be clear – we can not just record requirements and seal it. And then stay isolated from customer in building the software. One fine morning communicate to the customer that the product is ready and you are reaching customer site for product launch. If you feel that during the conceptualization, build and test phase customer has no role to play – you are wrong. If the customer thinks just by giving the requirements they will get a good product meeting all their expectations – customer is wrong. Both have to be in tune during the product development. If vendor fails to gauge the change in underlying business need that they are trying to cater to and think if they do so, it will increase their cost and time – again the vendor is wrong. By not doing so – they call for more time and cost. By not doing so – they surely call for more discrepancies, ambiguities, delays and failures. A small investment of time and cost during the build phase to involve customer and take his consent at every step will definitely lead to later on investments, time delays etc.

If attitude is not conducive, it has to be. Customer has to realize that. And customer has to realize the importance of getting involved in each phase of the project rather than assuming that it is vendor’s call and everything will go fine.

The requirements keep changing, as the business. Only thing that varies is the pace of change in requirements. Overlooking changes happening in the business process at customer end after freezing requirements will result only in undesirable product. Both customer and vendor have to understand this and keep overseeing the changes rather than overlooking.

If changes are not recorded and incorporated in time, customer is always going to blame the vendor and may be vendor gets exchanged with another vendor for the same project.

Jun 15 2009   10:00AM GMT

Do’s (+) and Don’ts (X) in Project Management

Posted by: Jaideep
change management, Project Management, resistance to change, Employee retention, employee engagement, Software Project, employee satisfaction, opportunity to grow

+ Do
X Don’t
+ Single constant in business is Change
X Single constant in business is resistance to change
+ Change means shifting to a better comfort zone
X Change means shifting away from comfort zone
+ Recruit well in advance before the project start time
X Recruit at the time of start of project
+ Give to new recruits the ample time and guidance to charge them well
X No time for relaxation should be given to employee
+ Relaxation re-energizes, recharges the employee
X Relaxation destroys the enthusiasm and fire of an employee
+ Retention of good employees is worth spending in case of no projects
X No Projects No Retention
+ Importance, Encouragement, Attention, Satisfaction, Opportunity to grow all these
are important for employee and it pays back to an organization
X Organization pays, Employees work
+ It is better to monitor new employee to check its readiness for appropriate job
X Recruit and assign directly to project
+ Shortcut is the longest route to achieve success
X Omit steps, adopt shortcuts and attain results
+ Do
X Don’t

Jun 10 2009   10:00AM GMT

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

Posted by: Jaideep
Project Management, Software Project, change management, project organization, developer, project sponsor, project director, project manager, key user, implementer, technical lead, business requirement study, business analyst, business analysis, requirement analysis, requirement gathering, implementation phase, project phase

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.

May 15 2009   10:10AM GMT

How to manage Change Management – in terms of scope of the project

Posted by: Jaideep
Project Management, change management, project scope, project schedule, Project Plan, Software Project, project manager, project progress, project role, project aspect, project study, project location

Scope defined and decided upon initially by vendor and customer mutually has a large impact on timeline, progress and success of a project. A change in scope at a later stage may call for a big impact on project schedule and progress. Let us see the roles of vendor and customer respectively in this aspect of project.

Vendor - Project Manager has to ensure that the scope of project defined in the Business Study Document has to be adhered to. Any change in the scope (increase or decrease) has to be escalated to both the managements and the project plan has to be re-designed thereupon.

Customer - The management and project manager has to ensure that they define the Right scope for the project (number of locations, pilot site etc.), also understand that any change in scope will adversely effect the project plan and hence seeks redefinition. The pilot site chosen should be the best possible site in terms of testing the software completely and rigorously.