Responsibilities of Product Owner with respect to Project Manager

Project manager lead the team for all aspect of the project (scope, schedule, cost, quality, human resources, communication, risk and procurement and their appropriate integration) while Product Owner lead the team for the product scope to ensure value is delivered to the business.

Project Manager is defined as integrator for all the aspects and balances the competing demands of all the pieces or aspects of project. A Product Owner serves to the Project Manager and plays a partner role with Project Manager in product scope where product scope is defined for both ‘Fitness for Purpose’ and ‘Fitness for Use’.

Project Manager is accountable for ensuring that the product is delivered to the customer on time and within budget. The Product Owner is accountable for ensuring that the product is built according to the requirements and is built correctly. This difference in focus is the reason that having both roles on the team is critical. The product will be built correctly, according to requirements, on time and within budget!

Product Owner responsibilities which incorporate both PMP and Agile processes: Product Owner is agile process role, but agile does not address all the processes of project management, so if we follow all the good practices of agile and PMP, following responsibilities can be identified for Product Owner.

1.     Project Initiation: When responsibility is delegated to Project Manager by Project Sponsor.

a.      Assist Project Manager to identify quantifiable product scope statement from procurement documents, development related extracts from project contract and Business Case.

b.      Contribute to identify product requirement related risks.

c.      Help to Identify requirements related communication needs

d.      Help to Identify estimates in PO related activities based on scope and complexity of product requirements.

e.      Support to identify estimates based on identified product scope and risk involved in product and included in project scope with identifying activities of project scope and other risk involved by the Project Manager

f.        Help to identify business stakeholders and to identify timing and level of involvement of stakeholders in defining and completing product scope.

g.      Assist Project Manager to identify ‘Fitness for Use’ for product that contributes to project success criteria.

h.      Identify Product Approval requirements with Project Manager

i.         Help Project Manager to identify resource needs with needed knowledge and skills.

j.         Work with Project Manager to identify schedule milestones.

2.     Project Planning:

a.    Release Planning:

                                                               i.      Involve cross functional stakeholders to brainstorm customer needs.

                                                             ii.      Development of QFD to objectively sort the product requirements to be included in identified project scope. Goals are set to achieve product scope.

                                                            iii.      Identify acceptance criteria and include in title, short description form associated with stories at this stage.

                                                           iv.      Complete development of Product Backlog and accountable any changes in product backlog.

b.      Sprint Planning Meeting: Work with team to fetch stories to be included in sprint backlog as per priorities set using QFD to ensure value is delivered to the business.

c.      Help Project Manager to develop and identify definite schedule, budget, revise resource needs, revise communication needs and uncertainties related to requirements for the current sprint.

d.      Help Project Manager to include identified product impediments as part of backlog with the intent to make sure structured attention of all stakeholders involved in the project.

3.     Design & Construction Interleaved (Planning and Execution)

a.      Define ‘Definition of Done’ of stories of sprints

b.      After preliminary design involve developers to identify unit test cases for the included stories of sprints.

c.      Develop detailed acceptance steps of acceptance criteria’s of stories

d.      Identify complete flow of stories in case of complex process flow involved.

e.      Develop static structure of stories involved in sprint. detailed acceptance steps of acceptance criteria’s of stories

f.        Identify Message flow within stories.

g.      Identify components and associated dependencies involved.

h.      Drive the team to produce product deliverables as per ‘Definition of Done’

i.         Make sure continuous integration

j.         Drive the development team to ensure vale is delivered to the business:

                                                               i.      Make sure ‘Fitness of Purpose ‘and ‘Fitness for Use’ of requirements of stories.

                                                             ii.      Drive the team to complete storied as per Definition of Done

                                                            iii.      Identify Vital Few  using analysis of documented results of causes of poor product quality

4.     Monitoring & Controlling:

a.      Involved in Daily Stand Up meeting  with Project Manager to identify:

                                                               i.      Technical blocks.

                                                             ii.      Requirement related risks.

                                                            iii.      Product Quality issues

b.      Work with Project Manager in requirement related changes control procedures. Involve in change procedure if change to project charter is initiated after sprint planning meeting.

c.      Continuously monitor requirement related risks.

d.      Involved to identify causes of poor Product Quality

                                                               i.      Make sure Development and Acceptance TDD and make sure recording of  causes of poor product quality.

                                                             ii.      Make sure Development and Acceptance TDD for a story before moving to another story by team to ensure visible project progress.

e.      Help project manager for status reporting in terms of Burn down chart and EVM system.

f.        Help Project Manager to forecast to update current cost and current schedule information.

g.      Monitoring implementation of requirement related changes.

h.      Involve in verify scope in which completed stories are demonstrated to customer to formalize acceptance of completed stories as per established ‘Definition of Done’

5.     Phase (Sprint) Close and Next phase Initiation:

a.       Involve with Project Manager in Sprint retrospective meeting and involve in development of repository of lesson learned and templates for similar projects i.e. WBS, risk register.

b.      Revise business stakeholder involvement with Project Manager

c.      Work with Project Manager and other stakeholders (i.e. Project Sponsor) to identify whether project is on track to deliver business benefits.

6.     Project Close

a.      Involvement with Project Manager in lesson Learned.

b.      Involve in final project completion meeting to identify project success to capture Business Need of project.

Seema Sonkiya

Seema Sonkiya: Management of Apportioned Efforts or Project Admin Activities

Article based on PMBOK 4 recommendations of apportioned efforts.

When project and product scope is identified, next step is to develop detailed project schedule. It is very important to identify discrete efforts (DE), level of efforts (LoE) and apportioned efforts (AE) very carefully to develop reliable and achievable schedule. Definition of these efforts can be found in another article: http://seema-sonkiya.blogspot.in/2012/03/project-schedule-development-important.html

As to recollect, AE efforts are project management activities which are independent from DE and play a crucial role in project and product quality. Example of apportioned activities but not limited to daily stand up meetings, timely updating of MPP and burn down chart, developing MOM of a meeting, developing and communicating status reports, updating project communication in timely manner, creating team directory, documenting ground rules, developing project organization chart, updating risk register, writing mails to client etc.

All these AE efforts are identified and delegated to team members as per their profile, work responsibilities and skills. Most of these activities are supposed to perform by the project manager or by the person under supervision of project manager, but project manager need input from other team members to perform AE and sometime he/she does not get this information due to other high value priorities of DE.

These apportioned efforts are performed to ensure that DE efforts are delivered effectively and refer to work that need to be accomplished to deliver product service and results and independent of DE.

We all know that AE identification and include in project schedule is very crucial but sometime these activities are overlooked due to many reasons like; but not limited to:

1.       Rushing planned AE to meet schedule objective like team in tight deadline pressure and priority is set to high for some DE and associated LoE and team intentionally overlooked AE.

2.       Project manager is heavily busy in customer communication, which included long discussion and not having time to perform identified AE and as current time priority is high to become involve in communication with key stakeholders.

3.       Some project team members are tightly involved to meet current sprint deadline because some obstacles encountered and resolution resulted in tight work pressure. As a result they are not willing to perform AE, for example team members are not providing timely status that is needed to update burn down chart daily and key stakeholders are not communicated properly about remaining outstanding work in timely manner.

4.       Project Manager is on leave and other responsible people are busy in other DE activities. When project manager joins office there is long list of AE backlog items that are performed in daily basis. Now project manager become busy in communication with key stakeholders and able to perform only those AE efforts that are planned in current time period. Past activities are overlooked.

5.       Project team members are less educated about the importance of AE.

6.       Project team members do believe that success of their work will be measured by the DE and associated LoE and less interested to perform AE.

7.       Project manager got early morning call from client and attended from home and in result could not reach to office in time and some planned AE activities skipped as when he/she reached to office other efforts priorities become high.

8.       Some urgent DE efforts are need to be delivered next day and some team members along with project manager stayed late night or till early morning and when completed they just left and they did not update plan what has been accomplished. Now suppose other team members who come on time next day and their work is dependent on what has been accomplished last day. Team members who worked late did not come on time and next day work result in chaos.

9.       90% of time of project manager goes in communication with project stakeholders and involvement of project manager in high value priority communication is also one of key reason of AE overlooked.

All these examples shows that we need to devise a methodology in which in any circumstances whether predicted on not, these AE are not overlooked. Overlooking may result serious consequences; for example establishing and maintaining team directory is an important AE. As an example, we assume a scenario, mobile number of a team member gets changed and updating is overlooked.  As a result project manager will not be able to contact that team member, if he/she is on leave and some critical situation arises and few information from him/her needed.

Here I would like to suggest a solution that we have implemented and in result we are working in hassle free environment and it took stress away from everyone involved in the project. Major benefits of this solution is that we are meeting deadlines more than 99% of time because it helped us a lot in removing impediments.

Most of the AE activities that frequently get overlook include documentation that have been identified, accepted and accomplished and needed for further reference. My recommendation is to include a role who is involved to assist project manager to perform these AE.  We should develop guidelines or rules of engagement between PM roles and the admin roles.

Admin role make sure that all of the AE activities performed in timely manner regardless of circumstances. They work under supervision of project manager.

Here I would like to refer how we implemented the solution. I am involved to manage more than one project and for those projects two admin person appointed who work in shifts. First admin come early in morning and other one join office in post lunch to ensure availability of admin role all the time and also help to coordinate time zone problems. Morning admin, who reach to office approx one hour early from other project team members, refer the MPP, burn down chart & communication that is received from client and develop and/or update detailed assignment sheet for the team members may be with the help of project manager. Second admin person who come in post lunch first understand the current situation from morning admin and involved till late hours. As a result both early and post lunch admin make sure that AEs never overlook in any time and help team to perform as there is someone who is doing AE all the time.

They Run errands where and if necessary, to help the team focus their work on their high value functions and activities. It also helps to greatly reduce uncertainties and gives an environment where risks and issues are identified in timely manner and documented. As these members get mix in project team members, help project manager in observation and conversation tool to manage project team members. They help project manager to provide accurate information how well team is performing collectively and individually. They are authorized in leadership as a representative of project manager especially in absence of project manager.

As we know project manager involved 90% of time in communication with project stakeholders, involvement of admin roles make sure that these activities are performed without worrying about AE that has feature to get overlooked.

Our admin roles assist project managers to perform all of the admin work like updating MPP, burn down, risk register, observing team member’s attitude, writing correspondence to client whenever needed etc.

One of the main goal of project manager is to focus team members to their core work and this solution is perfect in achieving that and leads to team members satisfaction and result in less staff attrition, as we know most of team members especially technical one are less interested in AEs.

Seema Sonkiya

Seema Sonkiya: Project Manager Role in Development of Project Charter

Article based on PMBOK 4 recommendation of project manager role in project charter.

Project Charter is one of the most important documents for a project. It is developed to establish an agreement or partnership between technical and business organizations. Technical organization delivers product, service or result which is requested by business organization. Project cannot be started from planning processes until project charter formally approved.

Project Sponsor is accountable for the success of the development of project charter, this information really confuse some professionals (I seen even certified professionals confuse with the fact) as they misunderstand that meaning of this truth is that project manager is less or not involved during the process. Project manager may or may not heavily involve during project charter development. Here I am trying to put forth the role of project manager during development of project charter.

Firstly, here is a need to understand difference between accountability and responsibility. Responsibility may be shared between members involved but accountability is not shared. Accountability may be defined as ultimate responsibility.  Accountable person is ultimate answerable for the correct and thorough completion of a process or task and the person who allot or delegate the work to those who are responsible.

Project manager is accountable for the success of the project during planning, execution, monitoring & controlling and phase initiation (note project initiation is not included) processes. Successful accountable person need clear authority to use company resources, make decisions, expend fund, or give approvals. This authority is established during development of project charter. Clearly a person who is external to the project is accountable to the success of ‘Develop Project Charter’ process who may delegate the responsibility to the project manager.

It is necessary to establish appropriate authority levels based on project and product scope, needed budget and range of stakeholders involved. Project initiation is the process where all of the project aspects are explored in high level form that is also needed to analyze and to establish appropriate authority levels for the project manager like authority to select team members and their use for the project work, signature authority for the funds and ultimate approval of deliverables before sending to the customer.

Project Manager should be able to know project end date and project budget always and this is included in project charter. Whenever project end date and budget changes, (even in planning, monitoring and controlling processes) its duty of project sponsor to update project charter and authority of project manager updated accordingly.

So if project sponsor is accountable for the development and updating of project charter then what is the role of project manager and other team members if involved?  Here are some details:

1.       All of the aspects of the project are explored in high level form, a team is needed and project sponsor may form the same and includes project manager and other identified project team members if needed based on complexity of the project. If team is formed then success responsibility is shared with all of the team members and ultimate responsibility lies with project sponsor who is senior to project manager and appropriate at the level of project funding.

2.       Project Sponsor either develops project charter or may ask project manager to create it, who is identified to lead the project. Project manager inputs are very crucial during development of project charter. Help of project manager is needed because he/she is the person who will direct the project and it is recommended to involve him/her to explore project particulars needed to identify and establish authority of project manager.

3.       As authority level of project manager is established so it is obvious that he/she cannot be accountable for the success of develop project charter process. How project manager authorize himself or herself?

In conclusion, project charter is authorized by someone external to the project and it should not be confused with the involvement of project manager.

Seema Sonkiya

Seema Sonkiya: Project Initiation Important Notes

Article based on PMBOK 4 recommendation of project initiation. Quality analysis concept are referred from function point and use case point analysis where we analyze how identified features and functions will be delivered. This article is especially designed for IT/software industry.

Project initiation processes gets started as soon as project is selected to produce a product, service or result. A statement of project and products scope and associated exploration of other aspects of project like summary schedule milestone, estimates for the forecast of company investment(resources needs and their engagement duration), summary budget, project success criteria (quality aspect at high level form), high level identification of risk, and need of supplier and/or purchase of equipments are identified.

All of these aspects are explored in high level form with the purpose to identify project success to capture the business need within the given constraints.

In addition roles, responsibilities and authority of key stakeholders are indentified along with their required and existing skills, knowledge, impacts on project success. Timing and level of involvement are identified with the purpose of identifying communication plan and their engagement during the project.

PMI identified two processes for the project initiation:

1.       Develop Project Charter: Project charter is developed in which all of the aspects of the project explored in high level form

2.       Indentify stakeholders: All of the person or organizations are identified impacted by project success and identifying their management strategy for the purpose of creating communication plan.

Project Manager is identified and assigned during project initiation and may be involved in development of project charter. Development of project charter is a process which set the authority level of project manager. Authority of project manager is identified during this process so project sponsor is accountable for the success of whole process group of project initiation though project manager is involved during project initiation. Company investment analysis is performed during development of project charter so it is important that project sponsor should be appropriate to take decision of project funding.

Steps for project charter development process:

1.       Analyze business need of the project so that after completion of analysis of all the aspects of project, we can conclude the probability of project success in the presence of all the constraints. Understanding business case of the project is needed. Business case captures the business need of the project. Project manager should know why the project has been selected so that he/she keeps the business case in mind during project to ascertain that project will achieve the results for which it was selected.

2.       Contract of project is analyzed and excerpts are extracted to be included in the analysis and development of project charter. For example summary milestone and budget may be included in project contract.

3.       All the documents that have been provided by the client as product scope description are analyzed. Project proposal that is sent to client as official offering from the company, communication that was performed with the client during project selection process, MOM of the entire phone, chat & personal and/or virtual meetings are collected and analyzed. Project procurement team members are involved to analyze all of the commitments that are made by the company during project selection process. It is important to identify project development related commitments done by the procurement team. This information is included in one or more 8 relevant aspects of the project with the purpose of integration.

4.       We need to identify the nature of project i.e. whether waterfall or agile model is suitable and phases of project identified accordingly.

5.       Explore all the aspects of project in high level form to integrate them in cohesive whole:

a.      Project and product requirement are explored in high level form (it is not true in fixed price contract). This is basically systematic arrangement of information contained in buyer and seller contract (development specific information), all of the documents received from and sent (i.e. project proposal) to customer during project selection and converted in modules and sub modules. High level project architecture is identified.

b.      Project schedule milestones are identified, at this level these are mostly taken from contract of the project.

c.      Quality management efforts are identified based on available information, mainly project success criteria. Cost benefit analysis is performed at a high level to determine what level of quality managements efforts are needed for the project. We cannot spend too much compared to benefits. Success criteria at project level (Low level details of quality i.e. How each identified features and functions will be delivered are identified during detailed planning) are identified like:

                                                               i.      Data communication: whether application will be delivered with more than front end UI and supports one or more type of TP communication protocol.

                                                             ii.      Distributed data processing: Whether distributed processing and data transfer are online? Processing functions dynamically performed?

                                                            iii.      Performance: Whether Response time or through put is critical during all business hours? In addition, performance analysis tools need to be used in the design, development, and/or implementation phases to meet stated user performance requirements?

                                                           iv.      System Configuration: Hardware needs of solution and analysis of security and timing considerations.

                                                            v.      Transactions: How frequently transactions executed: daily, weekly or monthly?

                                                           vi.      ON-Line data entry: What percentage of data entered online?

                                                         vii.      End-User efficiency Factors: End user efficiency is analyzed using many factors like navigational aids, online help and documents, remote printing needs, bilingual or multilingual support.

                                                        viii.      On-line Update: How much logical self contained functionality will be updated using on line transactions? Protection against data lost need to be programmed? High volume of online update brings cost consideration into the recovery process. Need of highly automated recovery processes identified.

                                                            ix.      Complex processing: Will application involve extensive logical and mathematical processing? Application needs specific audit or security processing? Need of exception processing resulting in incomplete transactions that must be processed again and complex processing to handle multiple input/output possibilities, for example multimedia or device independences are analyzed.

                                                             x.      Reusability: Whether application will be specifically packaged and/or documented to ease re-use, and will be customized for use by means of user maintenance? High reusable solution increase design complexity.

                                                            xi.      Installation Ease: How difficult is conversion and installation? Whether conversion and installation requirements are stated by customer? Need of Installation guide identified. The impact of conversion on the project is considered.

                                                          xii.      Operational Ease: How effective and/or automated will be start-up, back-up, and recovery procedures? Whether application is designed for unattended operations?

                                                         xiii.      Multiple Sites: Will the application be designed, developed, and supported to be installed at multiple sites for multiple organizations?  Whether documentation and support plan will be provided?

                                                        xiv.      Facilitate Change: Will the application specifically designed, developed and supported to facilitate change?

                                                         xv.      Concurrent Processing: Is the application looking at large number of users? As it will increase architectural complexity.

                                                        xvi.      Portable: Is the application looking for cross platform implementation?

                                                      xvii.      Direct Access to third parties:  Will the project depend in using third party controls? Understanding third part control may require considerable time.

                                                     xviii.      User Training facilities: Will the software from user perspective be so complex that separate training has to be provided?

                                                         xix.      Others: In addition other factors especially related to environment of project like familiarity of project, application experience, motivation, stability of requirements are analyzed.

d.      All these analysis forms the basis how identified features and functions will be delivered and used in estimation to make them as realistic as possible.

e.      Resources needed skills and competencies are analyzed, some resources may be pre-assigned.

f.        At this time project communication needs for the identified stakeholders are made explicit from all documents used as an input of this process. Especially contracts and product scope description. All the identified stakeholders are registered in stakeholder register. For example during analysis of product scope description it may be identified that customer is subject matter expert of project domain then this information may be entered in high level communication planning for further detailing of communication plan during project planning.

g.      High level risks are identified from all the available information; this forms the basis of range of estimates.

h.      Procurement needs are identified. It is analyzed that what equipment or technology need to be purchased. It is also identified whether any piece of project required outsourcing.

i.         After analysis of these aspects ROM cost is established. Range of estimates indicates risk involved in the project. Estimates should be supported by appropriate assumptions to avoid any ambiguity as estimates are based on available information and it may be possible that customer even unclear about some aspects and that need to be uncover in detailed project planning.

6.       Constraints need to be documented separately i.e. availability of right skills to the project.

7.       It is very important to analyze project charters of similar historical projects to analyze the current project aspects.

8.       Information is explored based on measurable project objectives.

9.       Include separately that what will not be included in the project from the product scope description and other documents used as an input.

10.   Finalize the project charter.

Steps for the stakeholder identification process:

1.       It is performed in parallel of project charter. Stakeholders are identified with the help of all the information used as an input for the development of project charter. As project charter process progresses, stakeholder register gets refined in other words Project charter used as an input.

2.       External stakeholders are mainly identified with the help of procurement documents, i.e. procurement information explored during project charter development process.

3.       Stakeholder analysis is performed and influences and risk tolerances are identified.

4.       As each stakeholder’s identification made explicit, their high level requirements and expectations are also made explicit in project charter using coordination of project initiating efforts with stakeholders including customer.

As project charter and stakeholder register including their management strategy developed, project sponsor’s signature make project officially authorized.

Seema Sonkiya