Generally speaking, you cannot separate projects from project management. It sounds like a 100% rational process but it is truly an art to handle the iron triangle of Quality, Time, and Cost.
Historically speaking, project management started its evolution in the industrial and construction projects, while, in the latest decades, it has been applied also to the IT domain, in order to materialize the vision of courageous entrepreneurs and investors: IT as a new "commodity" alongside already existing ones: oil, energy or, recently, the Internet.
If we go more specifically towards web applications development, I would like to use this opportunity to highlight the insights I have experienced as a project manager (PM) in project lifecycles with my current employer - ISDC, a European IT software and solutions company with expertise for enterprise clients in the fields of innovation, intelligence, and integration.
In what follows I will pass through the most important aspects that deserve the PM"s special attention in an agile project: from a short history about the evolution of development methods to the agile project start-up, identifying stakeholders, fundament phase, defining functional and non-functional requirements, change management, high-level planning, communication, risk management, progress monitoring, QA, management of visits, demo/UAT to client and concluding with the retrospective.
From the moment you are assigned the role of project manager, you carry a great responsibility: client satisfaction. A client can be an entire organization with a series of decision makers involved or a small group of persons. I strongly believe that client satisfaction is the essential vector in controlling the iron triangle and the development of a long business relationship with that client.
Everything starts even before the project start-up. The pre-sales and sales process is often long and full of challenges. Once the parameters of the collaboration with the clients are set and the contract is signed, the PM takes over these parameters and starts their refinement.
Agile or non-agile, a project needs to be managed in such a way that it reaches its targets under the conditions agreed with the customer and it also delivers the product desired by the customer at the right moment and within budget, complying with a series of complex technical and functional parameters, that define product"s quality.
Over time, specialists, engineers and business people have tried several working formulas to successfully complete IT projects and collaborate together. The well-known waterfall development method was used a lot in early IT projects, cascading phases of requirements development, analysis, design, development and finalizing with integration testing.
Several intermediary iterative methods followed, by breaking the monolithic waterfall model in smaller waterfall iterations or increments. Finally the development model that has imposed itself globally was the agile one, given its flexibility and shorter time-to-market.
When mentioning agile, I will refer in what follows to Scrum, as the development framework but there are for sure other methods too, like DSDM or Extreme Programming for example.
In most projects, I have worked with clients in complex organizational setups. This makes it difficult, sometimes impossible that all main stakeholders of the project join kick-off meetings at start-up. Therefore an important target for a PM is to know all its partners interested directly or indirectly in the project and in addition find out their stakes related to the project or product(s) delivered by the project. You would like to avoid the unpleasant situation when a stakeholder is identified too late, in the final phase of the project which could possibly ruin your plans and the final acceptance of the developed IT system.
ISDC offers its clients a fundament phase as part of the project, before the actual start of the development sprints. In this phase we can identify and communicate directly with the involved stakeholders. The benefits of the early step are tremendous; working teams (client and supplier) will know each other and they will align on the way of working plus other important project aspects. For sure this phase needs a clear plan and agenda in such a way that time is spent efficiently, covering the most important topics for the start of the development.
During the alignment of the supplier with the client, a gap of expectations on both sides might come up to light even from the sales phase. The PM needs to have his/her attention on the identification and clarification of these differences and pursue for common agreements with the client. These agreements refer to planning aspects as well, like defining project phases and milestones, number of development sprints, team size and even way of working.
In practice at project start-up, you need to cover a full range of topics in the client discussions: from functional/non-functional requirements, that influence high-level architecture and expected quality attributes, to the way in which software development and testing is done within your project. There is still the case when a list of open points remains. In this situation I recommend that the PM collects them and monitors them further till completion.
There are cases when you have to come back to certain aspects several times when the project is a complex long run. One situation I have met was the discussion and clarification of the NFRs (after project start-up) like performance, maintainability, robustness and security of the developed software system. You have to be careful with these, since they can have a big impact on the high-level system architecture and that is something your architect should tell you.
Changes of the NFRs, during the software system development, being a web application or not, might impact planning and project budget since they have a great potential of generating re-work or refactoring. For a fix price project it will give you the chance to exercise your change management skills to convince the client to pay for the additional changes.
Defining, clarifying and assigning the project roles from the start-up is essential. Starting from the governance at Project Board level and to the Scrum team roles: Product Owner (PO), Proxy-Product Owner (PPO), Scrum Master (SM) or Team leader (TL), Architect, PM etc.
There are certainly a lot of role setups that work; depending on the way of working, for example with mixed development teams (supplier and client) or only from supplier or in collaboration with sub-contractors and consultants from client side. Some roles can be aggregated, one PM can be also SM/TL, sometimes a SM is also PPO etc. In general, what needs to be taken into consideration when aggregating roles is to avoid the conflict of interests among roles and of course the internal organization of the software supplier.
Another lesson learned is that there are customers who know exactly what they want but there are many that cannot indicate the details and those need to be guided. In the end, as a software services provider, one of the challenges we have is to guide the client to the best solution that develops and improves their business.
Here comes in picture the definition of functional requirements, whether it is done by the customer"s business people together with specialized consultants or by the software provider in collaboration with the client. Since the transition from waterfall to agile, detailed requirements definition is done in steps, having the development team involved in those pre-grooming or grooming sessions before each sprint. Rarely do we have complete functional specifications and even then, at implementation time they are already obsolete. Therefore, a preliminary per sprint prioritization of the major functional requirements (epics) from the product backlog is desirable. This needs to be done together with the client. As a PM, you need to ensure that the prioritization is realistic and approachable from the technical and functional perspective, after consulting your team, including SM and architect.
For a fix price project refining the major requirements (epics) into more depth (detail them in userstories) in advance might prove necessary. We need it in order to establish a clear delimitation of the project scope. This delimitation is one of the big challenges for a fix price project.
In order to guard the project scope it is recommended to setup the change management that consists in: defining a process (change management flow) for reporting & approving change requests and identifying the actors with their responsibilities in this process (client, team, OP, PM, Project Board, etc.).
The Change Request (CR) definition should be crystal clear for the development team. The role of the PM in this circumstance is essential; therefore a good collaboration with the SM and constant alignment is mandatory. Any request from the client that triggers a potential change needs to be notified by the team to the PM.
A high-level project planning takes into account the budget, the roles" effort needed in the team per sprints/weeks, a breakdown in time of the budget (hours/money) and a sequencing of activities and milestones on completion of work stages.
Planning should take into account the assumptions from which the development team starts, that may be technical, functional, etc. Their diversity is surprising. They come bundled with the project constraints that you find all over, like budget in most cases, delivery time, quality attributes, availability of both client and your team members. And, last but not least, planning is related to the risks identified at the beginning of the project.
The high-level planning has to be validated internally in the supplier organization and with the client even from the project start-up, with the remark that it holds in the context of the list of assumptions, constraints and risks. For further changes that appear in the assumptions list, the PM has to determine their impact on the baseline planning.
Communication is one of the key success factors of a project and the PM is the one that orchestrates it.
Often communication is neglected and then miscommunication impedes the smooth running of the project; nevertheless there are some things that can prevent such problems if they are set in place:
Indeed this is about risk management. Consider the risks as something with destructive capacity for your project. Certainly there are also opportunities but now I mean just the negative risks. Wouldn"t you want to treat them carefully? "Defusing" these risks should be among PM"s main concerns.
This is something I do permanently in projects I am involved: reduce the likelihood and impact through various actions. This is part of a PM"s daily activity. Along with the team and the SM, the PM has to identify and find ways to reduce the damage in case risks occur. Furthermore, transparency is needed in the team for these risks to be put on the table by its members. After that we need the perseverance of the PM to document, monitor and mitigate them. There are even cases in which some risks should be put on the table of the Project Board.
Risks should be collected permanently by PM/SM/Architect, in all circumstances. Do not confine it to just asking team members during daily stand-ups. Occasionally participate as observers at technical meetings, sprint planning and grooming sessions, in this way you will identify new risks. Talk regularly with your team members, so you gather along the daily impediments also the risks the team and project are exposed to.
Measuring progress is a key factor in determining the success of a project and applying the right corrective actions. Currently, there is a multitude of software applications that facilitate development teams with storage of functional requirements, acceptance criteria, activities status and initial estimates, time spent on activities, connection with the source code, code review remarks and more.
In recent projects I have worked on, we used JIRA (Atlassian) or TFS (Microsoft). Using the burn-down charts of these applications you can identify daily during a sprint if progress is as according to the initial sprint planning. In case of deviations the PM together with the SM can take corrective actions. Periodically, once a week for example, you as a PM can check out the budget status (hours/money) as well.
In the case of a fix price project, it is useful to have a description of the product(s) that your project has to deliver, with a breakdown on functionalities, this is called PBS (Product Breakdown Structure) in which you can fill the percentage of implementation of that functionality and you could also have an effort estimate to completion of what is left to be implemented. Most of the time, you can derive the PBS from the product backlog.
Delivery times, effort and cost are not everything; the developed software system must have certain quality attributes desired by the client.
In ISDC I had the opportunity to ask for expertise on the functional, architectural and quality of development and testing processes. This expert opinion input gave me an objective indication of the health of the software system developed and of the processes used within the project.
The default "built-in" mechanisms for source code review and functional test execution, found in the best practices of many development teams, offer you the certainty that no serious technical or functional error escapes the quality checks. In addition I would also recommend, during the life-cycle of a project, the following actions:
There are impediments and problems that cannot be removed by the SM/TL and so they get to the PM"s table. In this case, as a PM, it is necessary that you identify alternatives and means to solve them: you communicate directly with the customer, resolve resource issues or if you cannot solve it yourself, you have got a powerful and influential instrument the Project Board, before which you can bring the problem with the proposed alternatives. But do not surprise the board members, timely prepare an agenda and communicate it, fix a date when all members meet and clarify what you expect from them.
One of the major problems in many projects is the lack of availability of key persons on the customer"s side. To tackle this, I propose you to organize a common joint planning session with the persons concerned from the client or their manager.
Basically, such a reconciliation of the planning, made by the development team together with the key partners from the client, will lead to better results and commitment from both parties (supplier and customer).
Another common cause of bottlenecks and unsolved problems is the lack or scarcity of in person meetings between the development team (or its representatives PM, SM, Architect, PPO) and client (or their representatives: peer PM at customer side, PO, Key Users, Test Manager etc.). The PM is the one able to propose the client as part of the communication plan: a schedule of mutual visits to remove barriers and foster communication between members of both teams.
Whenever you can, plan a demo with the client or an acceptance period: a User Acceptance Testing (UAT) on-client-site or invite the client on your site. It is vital for the success of UAT to be close to the customer. Plan visits to the client to demo the latest features developed or to begin a period of UAT. You may encounter resistance due to the travel costs but argue by presenting the potential benefits.
At least at the end of each work phase (a new version for example) consisting of a sprints series, is useful to have a moment of retrospective with the team and the client, to analyse project parameters like: estimates deviation, re-work level, quality of userstories, code and test scripts quality. You may want to do this in separate sessions, but it is better to identify with your team things that worked and you wish to keep and things that you should avoid repeating in future.
From my perspective, a PM in an agile project should be dynamic, flexible and receptive to the short feedback loop from the client and team, while the PM focus remains on customer satisfaction and quality of the system developed within the budget and on time. These targets are achieved through sustained communication and stakeholder management, periodical presence on-client-site, constant evaluation of the progress together with the customer and the decision of implementing CRs, identifying and reducing risk impact conjugated with effective QA.