Whitepapers & Articles on Project Management Methodologies

1. Project Management Methodologies.
2. Do Your Homework.
3. Why is Project Happening?
4. Who is the Project for?
5. Identifying Roles and Agenda.
6. Manipulating Roles o Your Advantage.
7. What is the History of the Project?
8. What are the Anticipated Prerequisites of the Project?
9. Business Requirements.
10. Sope.
11. Timelines.
12. Budget.
13. Commercial Terms.
14. Look and Feel.
15. Technology.
16. Support.
17. When to go the Extra Mile?
18. Choosing Your People.
19. Project Manager.
20. Account Manager.
21. Lead Architect.
22. Software Architects & Engineers.
23. Senior Designers.
24. Working Practices.
25. Your Client's Role.

Project Management Methodologies

Project Management is the most important is the most important part of the creating a web application. You may wonder whether a software architect can effective projects. Certainly Yes! This article explains You hoe to collate businees requirements into a coherent brief and how to respond appropriately with a rock-solid specification and project plan . This article discusses tips to identify and select the key personnel You need to work underneath You, as well as how to guide and manage them throughout the project.

Do Your Homework.

A Project Management methodology can be made successful only it is applied frm the beginning of the project. Tracing the roots of any project essential.

Before taking any steps for proceeding over the project You have to first be clear with Your homework. You have to first get answers to the following questions.

Why is the Project Happening?

You must know the reasons behind making this project before its implementation. Basically there are three main reasons:-

1. Starting a new business for which "the business is the application."
2. replacing an existing application that is failing or no longer adequate.
3. Taking over where an existing supplier has failed to deliver either on time, on budget, or what is required (or in some cases al three).

Who is the Project for?

It is necessary that You identify the recipient of the project in the sense of who has actually commissioned the work. Say if a man goes to he store to buy his wife nail polish, he's not the real customer, he is simply responding to the real customers request.

Similarly, Your client may be commissioning his work for the third party's requirement. This ultimate end users of the product are known as domain experts. It is necessary that You satisfy the need of the end users and not the one who approaches to You in relation to the project.

Identifying Role and Agenda

This can be better explained with below example:-

Let us assume that You are the CEO of an organistion and have been ordered by the Human Resource director to build an Intranet for Your companyThe various Agendas of each role here are..... You, the client, the domain experts.

The scenario will look like this:-

• You wish to deliver a high quality, effective, efficient, satisfactory solution as quickly as possible and with as little investment as possible so that Youlook good
• The HR Director wats You to deluver a high quality,effcetive, efficient, satisfactory solution that makes himor her look good.
• Daily users of the Intranet (the domain experts) want You to deliver a high quality, effective, efficient and satisfactory solution that does what they want it to do.

Note :- That the only pure agenda here is held by the domain experts. The secret is to ensure that all three agendas are met. The first two are incredibly easy to meet, but by concentrating on the third, the first two will generally drop int place.

Manipulating Roles to Your Advantage

It is easy to impress our client with what You deliver and walk away. But its not necessary that what impressed Your client will impress the end users i.e. domain experts too. If the domain experts dont like it they will fall on the clients head and so on You. A good client will be able to sympathing You with the true needs of his or her domain experts. But if You feel Your client is not giving You sufficient information about domain experts requirements, then You can try getting the information through the consultative process:-

• A brainstorming session.
• An anonymous suggestion box approach.
• Appointing a working party to represent the needs of domain experts.

What is the History of the project?

It is vitally important to know the history of the project. It means that if the project has some negative aspects the people working on itand other such aspects. For example:

• If the project was handled previously by some member or a staff then You should find the reasons why they were removed from the project. You should know what the client requires along with the project.
• If the project has been replaced from an old supplier to You then its worth sizing up the reasons that the client dropped that supplier or the suppliers experience while doing usiness with this client wil want to trust You, so give im good reasons to.
• Many projects are actualy outsourced by a company. You may find difficulty working with the clients company's IT department. the best advice is to get that IT department involved from the start. Give the department a call while You're writing the technical specification - it will be caught well and truly offgaurd and may even prove to be a great help as a result.

What are the Anticipated Prerequisites of the Project?

You should make Yourself clear with the anticipated prerequisites of the projects like:-

• Language -Whether the clients requires the project in HTML, PHP, ASP, or ASP.net.
• Deployment - Does the client requires to deploy this web application into existing servers.
• Time scale - Make sure about the period in which the project should be delivered.
• Budget - You should make sure if the client is ok with the budget. Is it realistic?

Converting the project details and agreements into hard copy :-

The most important part before starting the project is to get the formal brief written into document. Getting the brief insures that You and Your team are able to respond to it in most effective manner.

If the clientscomands more features to avoid confusions. Wherever possible tryto glean aphone conversation or, ideally, a meeting with the client before writing the brief and responding to it.

Business Requirements

Establish exactly what the broad requirements of the system or applications You are building are at this stage. Focus on asking questions about the goals of the domain experts rather than the anticipated solution the client has in mind. Look at the generic questions for business rquirements:-

• What other solutions have You looked at?
• What have You rejected?
• How are You currently handling this process without a system in Place?
• What benefits do You think the system might bring?
• What kind of return on investmnet were You looking for?
• How are you currently handling this process without a s ystem in place?
• Who will the end users of this system be?
• How will You measure that return?
• What are the three most important requirements You have of a supplier looking to provide this solution to You?
• How many other suppliers have You looked at?
• How satisfied have You been with the proporsals You have recieved to date?

Scope

Till now we have established the broader business requirements of the system and studied what the system and studied what the clients are and how will we come up to their expectations. Lets be clear with the scope of the clients requiremnts.

By establishing scope You can prvent extra requirements coming in the middle of the Project without regard to commercial impact.Scope can prevent this uncertain requirements by drawing phase boundaries which helps us manage expectations even at early stage.

Timelines

It is vitally important to st milestones and gree to them with the client even at this early stage. Establishing timelines is about much more than just figuring out when the client needs the system to be delivered.

Budget

Budget can be a thorny issue, whether the concerned deal is within the company or with an outsider. However You should be clear while dealing with the client regarding budget issue. Budget should never be asked at an early stage of a meeting.

Till the time You study the clients nature, his capacity, his requirements in the conversatons goin around, the right time is probably close to when the subject of scope is raised, because You have already established that scope is more than likely going to be limited by time and money.

While giving price to a client for the project carried make sure that You dont offer a broad price range. For example: I have worked with XYZ company for similar project and the company has invested anywhere between $25000 and $45000 -neutral. By suggesting a broad price range, You suggest subconciously to the client that You still hav yet to zeroin an exactly that is required. For knowing the client budget for the project You should not directly ask the client what is Your budget, he wont reply. Instead You should quote him first a range suitable to the project. If its agreed the client will give a positive eply but if not he will state his budget for the project. and then its on You to accept the price for the project or not at the clients budget.dont get embarrased asking about money. Be up front, and pick Your languag and Your timing carefully.

Commercial Terms

Research suggets that a meeting in which parties have used positive words and body gestures leaves a far better impression than one lithered with no's and shakes of the head. As with budgetary concerns, its far better to get the issue of commercial terms out of the way early so that if they prove to be stembling blocks, You can be aware of them now and back out if necessary.

Some questions are worth asking if You have payment related concerns like:-

• We normally like to ask our client for an up-front percentage contribution so that we can cover any incidental costs during the build process. Would this be a problem?
• Because we're a small company, we have to be quite strict with our payment terms. All our invoices are strictly 30 days. Do You think this would be all right with Your accounts guys?

Look and Feel

There is no excuse these days for even the simplest of Web Applications not to look good. Design needs to be an integral part f Your process, not just an after thought, and this should be emphasized to the client whenever possible.

Determine at this stage whether any requirements or specififc requests exist on the part of the client with repect to the look and feel of what is being produced. Is there an expectation. For example, that a particular corporate branding is followed. Does the system need to closely resemble an existing system? How likely is it that the branding will change, and how often!

Technology

The individual Yo are dealing with from the clients company need not be a technical person. taking this in mind, its immensely important that You prove questions front of the client about technology to be used. You should explain him the pros and cons of the various technology that can be applied to the project and last but not the least You make sure that the technology to be used if PHP, HTML, ASP or ASP.net should be specified in formal brief.

Support

There's one thing You should always try to raise with the client, it's the issue of after-production support. It may not have even crossed a clients mind but its extremely useful to establish what the clients expectations are and how they tally with Your own.

Determining who will create user-oriented documentation (if required) who is to provide support after the systen is deployed, and what kind of service the client expevts during handover, are all important issues to address. If the client appears at a loss, attempt to suggest suitable answers to Your own questions, and gain clients tacit approval for inclusion in Your pitch.

When to go the Extra Mile

Some clients will really make You work to win the business. In many cases, its well worth it. At other times, it can be too much a risk. Knowing when and where not to go the extra mile is an essential skill, Dont think of this as being lazy; Your time may be far better served chasing down other potential business tools instead of pouring effort into an unlikely candidate.

The client can ask for on-site presentation, demonstration of similar systems You have developed in the past, and even refrences and testimonials from past clients. Its on You to accept it or not. For making easy the situation You should ask the following questions to Yourself like:

• How likely are You to win the business?
• What are the costs involved in taking these extra steps?
• What are other suppliers doing?

Choosing Your People

Before You cn get started moving the project forward, You need to assemble a team to work on delivery. You should set aside a full day for this process, if possible and make it clear to the client what You're doing. How big this team ends up being is obviously governed by the resources available to You and the requirements of the project. Lets look at the different roles in the project, and how al fit together.

Project Manager

The Project manager has responsibility for the day-to-dayrunning of the project, from the pitch right through to delivery and handover. Generally speaking, the project manager works directly with the senior members of the build team and if there is no Account manager handling the relationship with the client directly.

The Project Manager sets intrenal deadlines and objectives that are compatible with the broader goals for delivery of the project, manages progress, and identifies and resolves any conflicts or difficulties encountered by the build team throughout the project.

Account Manager

The Account Manager doesnot het involved in the day-to-day running of the project itself,but is instead concerned with managing the relationship between client and supplier. However, it is important that the Account Manager and Project Manager communicate on a regular basis so that the Account Manager abreast of the expectations of and feedback from the client, and that the Project Mangaer may make the Account manager aware of the progress and attainment (or otherwise) of key project milestones.

The ideal Account Manager is a gregarious and warm individual, the kind of person who can easily strike up and maintain a rapport with everyone he or she meets.

Lead Architect

The Lead Architect for the project is the techncsal decision maker or the entire project lifecylce. It is his or her responsibility to translate the immediate requirements of the project, on a day-to-day basis, into decisins on how those requirements should be realized through technology.

In addition to posessing thorough competence as a software architect, The Lead Architect must have a thorough understanding of systems and networks, such that he or she may suitably devise any deployment infrastructure that the project may require.

Software Architects and Engineers

Any given project requires a number of software archirtects and engineers to work on the back-end technology behind the application.

The difference between the two roles is one of seniority. A software architect has a degree of autonomy within the confines and standards st by the Lead Archirtect, to make decisions on architecture, layout, structure, infrastructure and coding standards. By contrast, a softare engineer must follow the edicts and standards set out by the software architects.

Senior Designers

The deisgn process is headed up by senir designers who are responsible for the overall conceptua design of the application bing produced. They will produce initial designs fo approval by the clint and make broader decisions on fonts, colors and imagery. They will work with the Lead, Architect in making such decisions to ensure that the concepts being created are within the technical constraints of the project.

Working Practices

As far as possible,its verygood idea to try to have Your project team workin one room together. That way, the often talked about and largely theoretical concept of synergy becomes one step closer. That is to say, that extra competive edge derived from having a workforce whse strenght is grater than the sum of its individual. Perhaps more important is having Your whole team under one roof makes Your job as Project Manager that much easier.

Your clients role

It is just impotant that your client defines distinct oles for the project and assigns personnel to those roles as it is that You have Your own team structured correctly. This is obviously something over which You have cosiderably less control than You have over the allocation of roles in Your own Project team.

However, if at all possible You should ensure that Your client assigns a relationship manager to act as Your first point of contact ith the client, to handle, raise and address any queries egarding the project, as well as any commercial queries. The client should also assign an internal project manager who should be required to provide any regular input into the roject-typically, providing content. this individual is reponsible for work at the clients end needed to provide You with this content.