Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
Before you can 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. Let's look at the different roles in the project, and how they all fit together.
If you're reading this chapter, this is a role that you will probably occupy. The Project Manager has responsibility for the day-to-day running 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, with the client directly.
The Project Manager sets internal 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.
It is not a technical role in itself, but having a thorough understanding of the work undertaken by software architects, software engineers, and others is all but essential to be an effective Project Manager. The ideal Project Manager, therefore, is an approachable, technically aware, highly organized and efficient individual, with a proven track record in delivering projects on time and on budget. Any given project should need only one Project Manager unless a specific requirement to the contrary exists.
If available, an Account Manager is a valuable addition to your project team. The Account Manager provides the sole point of contact between you (the supplier) and your client. All communications in either direction are channeled through the Account Manager.
Should the client have a particular request of the build team, they would put it to the Account Manager, who would in turn pass the request on to the Project Manager. The Project Manager would then handle the request internally, working with the build team as appropriate.
The Account Manager does not get 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 may keep the Project Manager abreast of the expectations of and feedback from the client, and that the Project Manager may make the Account Manager aware of the progress and attainment (or otherwise) of key project milestones.
An Account Manager is not essential but does often provide a closer, more fruitful relationship with the client, because the role does not have the team-focused responsibilities of that of the Project Manager. By the same token, however, this can sometimes lead to Account Managers being rather too quick to agree to demands of clients, because the burden of the actual implementation of such demands does not fall on their shoulders.
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. In addition, the Account Manager must be sympathetic to the limitations of what can and cannot be accomplished by the rest of the project team, and able to communicate these limitations to the client when necessary.
As with the Project Manager, only one Account Manager should be assigned to any given project.
The Lead Architect for the project is the technical decision maker for the entire project lifecycle. It is his or her responsibility to translate the immediate requirements of the project, on a day-to-day basis, into decisions on how those requirements should be realized through technology.
The Lead Architect on any given project will always be a software architect rather than an engineer, and hence considerably more experienced. However, the Lead Architect will also need to have some degree of project management experience to ensure that his or her decisions are client led; the Lead Architect should also possess exceptional team-management abilities, as more junior technologists will report directly into him or her.
In addition to possessing 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 infrastructures that the project may require.
Typical software architecture duties undertaken by the Lead Architect include creation, ratification, or both of the database schema and object model for the project, maintaining coding standards and holding regular code reviews. Given the scope of this position's duties, only one Lead Architect should be assigned to any given project.
Any given project requires a number of software architects and engineers to work on the back-end technology behind the application (in the case of this book, PHP).
The difference between the two roles is one of seniority. A software architect has a degree of autonomy, within the confines and standards set by the Lead Architect, to make decisions on architecture, layout, structure, infrastructure, and coding standards. By contrast, a software engineer must follow the edicts and standards set out by the software architects.
If resources do not allow for the use of client-side developers (see the following section), software engineers may also be assigned the task of developing templates and HTML for use on the site.
Of course, there need be no limit to the number of Architects and Engineers which can be assigned to a project.
The responsibility of client-side developers is solely to produce the HTML, CSS, and JavaScript that provide the user interface to the application being developed. Generally, they will work in a template-driven environment using, for example, Smarty Templates. There is not generally any requirement for them to know PHP or any other server-side scripting language.
They work with the senior designers and studio artists on any given project to receive the designs for preparation in HTML, but will report directly to the Lead Architect. There is no limit to the number of client-side developers who may be deployed on any given project.
The design process is headed up by senior designers, who are responsible for the overall conceptual design of the application being produced. They will produce initial designs for approval by the client 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 Usually, a project has no more than two senior designers.
Senior Designers have a more junior resource at their disposal, too that of studio artists. Not assigned creative concepts per se, studio artists are still skilled in Photoshop, Illustrator, and other design packages and typically respond systematically to requests for particular components; for example, the production of a navigation bar with a certain set of captions would normally fall under the responsibility of a studio artist.
Studio artists will typically work only with existing templates, styles, and colors set out by the senior designers on a project, and any number of studio artists may be deployed on a given project.
Resourcing can often be a problem, even for the biggest of agencies. With this in mind, the following pointers may be helpful should you be forced to double up roles:
Project Managers often make effective Account Managers, provided that they are client-facing by nature.
The Lead Architect can, obviously, perform all the roles normally performed by software architects and software engineers.
Software engineers can usually do the development work assigned to client-side developers.
Senior designers can, of course, perform all the duties normally assigned to more junior studio artists.
As far as possible, it's a very good idea to try to have your project team work in 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 competitive edge derived from having a workforce whose strength is greater than the sum of its individuals. Perhaps more important, having your whole team under roof makes your job as Project Manager that much easier.
It is just as important that your client defines distinct roles 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 considerably 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 with the client, to handle, raise, and address any queries regarding the project, as well as any commercial queries. The client should also assign an internal project manager should the client be required to provide any regular input into the project typically, providing content. This individual is responsible for managing or carrying out any work at the client's end needed to provide you with this content.