project phase

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 9 2009   6:29AM GMT

Project Lifecycle – 2012

Posted by: Jaideep
Project Lifecycle, Software Project, project team, project phase, tester, developer, software development, software testing, implementation, software product

Phase I: There is nothing called ‘off the shelf” product. It is all ‘made-to-fit’ technique. You specify your requirements and that too at a broader level. For micro level leave a red-mark at areas that need to be looked into at the time of building of software. The more red-marks will mean less precise plan and deadlines. The sooner we are able to convert these red-marks (not clearly known ones) to the clearly defied requirements, the better plan we can submit.

Phase II: The requirements will go to a team of developers who will build the outline or prototype of what is required by the customer, will get is approved from them and then will build the business requirements in it. Once they are through with it, the product will go to phase III.

Phase III: The product is handed over to a team of testers. These testers are technically stronger than the team that built the product. So this team will take the total ownership of the product from the team responsible for phase II. This team will find out the bugs, remove the bugs, fine tune the bugs and will hand over the final product to the implementation team.

Phase IV: The implementation team will interact with phase III team for any shortfalls in the product. Any new requirements will go to phase II team. Post implementation support also will be with the same team.

Sep 25 2009   10:00AM GMT

What is the ‘unit to measure’ your project progress?

Posted by: Jaideep
Project Management, project progress, Software Project, project initiation, project closure, project feedback, project execution, Project Planning, project team, project milestone, project phase, Development, testing, UAT, QC, quality control, test report, sign-off, implementation, live run, project task

A project starts with initiation phase and ends up with project closure report. Then afterwards there is post project feedback (after a considerable amount of time given to the customer to get conversant with the product) and warranty support followed by support contracts over a period of time. Let us begin our story with the project initiation and proposal approval from customer. The real ball-game starts from here.

Now planning starts, teams are formed, milestones are set and teams move into execution phase.

Execution phase comprises of development, customization, configuration, testing, training, reporting, sign-offs, monitoring upto implementation, parallel run, live run etc.

And then comes the project completion phase with Project sign off.

During all the phases of project initiation, planning, execution… are the milestones broken into tasks and tasks further into sub-tasks unto the smallest measurable, achievable ‘hour’ unit. Or it is measured in days, weeks or months where it loses its continuity and rhythm. If everyday something is declared done, finished, achieved that is visible to the project team, stakeholders including customer, it carries out a satisfaction, rhythm, confidence and regular progress.

Aug 12 2009   10:00AM GMT

Seven Questions on ‘Average Cycle Time’ of your projects?

Posted by: Jaideep
Project, Software Project, Project Lifecycle, project phase, project execution

What is cycle time?
Cycle time in terms of a software project is the time taken from its initiation to handover. Another measure in terms of commercials could be order to execution to recovery… A project lifecycle in other terms

Do you measure it?
You might be banking on your experience without any data in place!

What is your definition of project cycle time?
In your opinion it might be what I said above. It might be nothing for you! Or might be some other definition!!

Is it merely based on gut feeling and past experience?
If you are not recording the development of a project from one stage to another, your cycle time measurement sheet could be a blank sheet.

What is objective measurement?
As we all know each project has several phases. Each phase is divided in milestones. One measure could be the time taken by each milestone from it planning to completion. There would be certain parallel activities. On the other hand some activities could be incremental in nature. Measure accordingly.

Do you segregate your similar type of projects?
You might be running different types of projects. Some could be similar to each other and may fall in one category. Another set of projects could make another category.

Do you know average game is successful for similar types?
An average cycle time worked out for similar set of projects falling in one category will work best for you for your future estimations and meeting those estimations. Else average may not work well and estimations may go haywired.

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

Outsource in a software project without losing control over it

Posted by: Jaideep
Software Project, Project Management, outsourcing, requirement analysis, requirement gathering, requirement freezing, software design, software development, software testing, documentation, project implementation, training, handholding, post implementation, Project Planning, project control, project execution, project component, project phase, project offload, project outsource

We learnt in earlier two posts about the strategic decision of a management to outsource a complete project or part(s) of a project depending on certain factors, and the factors respectively. In this post let us see at the various components of a project that are most widely outsourced or otherwise we can say these are the components of a project which can be outsourced. It is very less often that a project awarded to a company is totally outsourced.

We are talking about outsourcing an activity of a software project. The most important components of a software project can be listed as:
Requirement analysis, gathering and freezing
Design, development and testing
Documentation
Implementation, training and hand-holding
Post implementation support

These can further be broken into various sub-components under each component thereby creating a tree like structure to have a bird’s eye view of any project. Planning and execution for each phase or component comes next with control everywhere.

Outsourcing mainly is the resultant of constraints in an organization.

Jun 22 2009   10:00AM GMT

Role of Vendor and Customer in managing User Manuals

Posted by: Jaideep
Quality Assurance, User Manual, Project Management, Software Project, project manager, stakeholder, project team, project quality, quality, project walkthrough, build phase, project phase, quality control

As already has been discussed, User Manuals play a crucial role in any software project and are the solid bonding between product, users, customer management and vendor project team. The stronger this bond is the more comfortable and happy each stakeholder will be. Each player has to play a crucial role during the game of building of User Manuals. Both Project Management teams have to work hand in hand for that.

The quality of User Manuals has also been discussed in my earlier blog (Six Pack User Manual – how to build).

Let us discuss below the role to be played by the respective project managers in this regard:

Vendor Project Manager has to ensure that the user manuals are built along with the product development and are vetted/ approved by their QC team via a walkthrough. If need be they should as for draft manuals in build phase. If there is a foreign language issue, the Project Manager should also ensure that the user manuals are required in their local country language.

Customer Project Manager has to check that user manuals are complete in all respects, and checked thoroughly before handing it over to the respective key users

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

5 reasons of top level customer expectations missing in requirement study document

Posted by: Jaideep
Top level expectations, Software Project, Project Management, top management, requirement study document, business requirement, requirement study, project phase, user level requirement, organization level requirement

As stated in previous two blogs, top level expectations gathering is very crucial during the business study and requirement gathering phase. And respectively I mentioned how vendor and customer can be careful (and should be) about that. Although it is rare and unexpected, but there are instances where customer organization top level management may not involve in a new software development project. This could have various reasons but could lead to only a single road – where the end is DISASTER. If this so happens, the chances of project getting hurt are manifold. It will precisely and ultimately lead to project failure. The reasons could be many, but to my mind following come at the top:

1. Customer Top management presumes that their involvement requirement is only for signing agreements, papers, reviews and sign-offs. If that so, they will have almost negligible awareness that how critical it is for them to get their expectations and requirements (top level) during requirement study phase. After all it is an investment of time, resources and money. Instead of getting a jolt at a final stage about getting the unexpected or not getting the expected, it is better to explain right in the beginning their own requirements and expectations from the product in detail.

2. Vendor’s management role is very crucial during this phase. They have to take initiative in explaining the top management about the benefits of the product being proposed. How it is going to enhance the processes in the organization, the change in roles etc.

3. Assume a situation where there is a pressure from user level for a solution or a product at customer end. The management is not sure about the product. Without horizontally analyzing various solutions available, they decide to go for a particular vendor or product just for the sake for fulfilling requirement. Although it will be rare, but even it is there at a very low intensity, it need to be addressed.

4. Customer top level assumes that the solution being invested into is meant only for user level and not organization level. This is a wrong assumption. Any investment – small or large- has to have benefits for the organization and top management on the cards.

5. Customer top management overestimates their users and assume that they will be able to drive the project without top management’s involvement. This does happen but very rarely, in very organized structures.