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

Seema Sonkiya: Agile Testing

Article based on agile SCRUM methodology recommendation of project testing, this article gives insight about testing in agile development methodology. This article talks about V model in agile testing, TDD and collaboration between developer and tester including how issues and bugs should be treated.

Agile testing strongly support V model, this model establish relationship between development and testing activities. This model ensures quality control and quality assurance throughout the project.

When we complete project and product scope using agile sprint, correctness and acceptance which includes verification and validation are performed by agile practices. Reviewing documents and designs, daily stand up meetings, continuous integration, refactoring, performing development and acceptance tests, holding focused reviews, enhancing communication are performed by involving product owner and customer along with development team which also includes test team members.

Three important deliverables are developed during project that forms the basis of V model:

1.       User Cases forms the basis of acceptance test cases.

2.       Simple design and visual modeling forms the basis of continuous integration and refactoring.

3.       Coding forms the basis of development or unit tests.

 Agile testing wires TDD. TDD is the combination of   TFD (Test First Development) and refactoring.

Steps of Test First Development:      

1.       Add a test.

2.       Run the test

a.      If pass then add another test.

b.      If fail then make required changes

                                                               i.      If pass then continue development tests.

                                                             ii.      If fail then again make required changes

When a new feature introduced, we need to first analyze whether the existing design is best design possible that allow us to implement that functionality. Two possibilities are:

1.       If existing design is suitable then we proceed via a TFD approach.

2.       If existing design is not suitable then we refactor the design to change the portion of design affected by the new feature. This enables us to improve the quality of design and making it easier to work with in future.

A developer using a TDD approach refuses to write a new function until:

1.       There is first a test that fails because that function is not present.

2.       There is test case for the code to be written.

Using TDD approach, programmer knows what need to be writing to pass the associated test cases. Once the code is written, tests are executed as our new code may break many existing tests as well as the new one.

TDD requires a great discipline, because it is easy to slip and write functional code before developing associated test case. Pair programmer helps the developer to stay on track.

TDD is performed in two levels:

1.       Development TDD:

a.      Development test cases are identified and designed during design & construction interleaved section of a sprint execution.

b.      When we add and run developer test, two cases are possible:

                                                               i.      If pass then we either add & run another developer test case or go to acceptance test case.

                                                             ii.      If fail then we make required changes and then again run the developer test case.

2.       Acceptance TDD:

a.      User stories forms the basis of acceptance test cases.

b.      High level user stories are identified during release planning. During release planning we just identify description of acceptance test cases for each corresponding user story to enable estimation as realistic as possible, during planning preferably in range of +-10%. For example: Add customer use case may  include acceptance test case for user to perform standard wildcard searches on first and last name

c.      Detailed acceptance test case instructions developed during Design & Construction interleaved of sprint. Like for above acceptance test case instruction may be defined as:

                                                               i.      Remove all customers

                                                             ii.      Add some customers

                                                            iii.      Display the Customer search screen.

                                                           iv.      In the First Name entry field, enter "%ob*"

                                                            v.      In the Last Name entry field, enter "S*"

                                                           vi.      Press the search button.

                                                         vii.      Identify and validate expected results.

d.      When all of the development test cases associated with newly developed functional code successful, we execute associated acceptance test cases.

                                                               i.      Add an acceptance test

                                                             ii.      Run acceptance test.

                                                            iii.      If pass then add and run another acceptance test or stop development of that functionality.

                                                           iv.      If fail then make little changes and run again.

Some other important notes about agile testing:

1.       When a deviation is identified after establishing definition of ‘done’ for all the user stories of sprint and these are demonstrated to customer, then this deviation is treated as bug.

2.       Whenever a bug is discovered it is treated as backlog item that is related to specific user story already in backlog.

3.       Bugs should be treated independently for the tracking and prioritizing.

4.       Bugs and story should be prioritized at the same level as each other and they should be estimated using the same standard and technique. i.e. relative story point.

5.       An issue is an problem that occurs mid sprint and is tightly coupled to a user story that has not yet met its definition of done i.e. It is still in the state of ‘in progress’ or ‘ready to verify’

6.       An issue is not a backlog item; this is part of evolving development or acceptance test cases.

7.       Our emphasis should be to address issues as soon as possible.

8.       It is recommended to completely finish one user story in its entirely including testing and rework than to partially finish multiple user stories.

9.        When agile tester performing exploratory testing on user story, and discovers an issue. Some important items need to be take care:

a.      As a user story is completed in it’s entirely, this user story should be the top priority of the developer working on it. Tester feels free to walk over to the developer to explain or demonstrate the issue as soon as it is found. Again, due to top priority, the programmer should leave whatever they are doing and immediately start work on the issue. This is based on agile principles where face to face conversion is preferred way of communication and working software is primary deliverable rather than documentation.

b.      If the developer is busy to resolve another issue discovered by tester earlier related to same story, then these details are captured or documented for later discussion with the developer.

c.      When issue is discovered, it should be treated as part of the acceptance criteria of the user story. This saves the tester from the pain of having to create a new bug, classify it, assign it, prioritize it etc etc. Tester need to simply enter a line to the acceptance criteria with a date/time stamp, some bullet points related to issue. When developer is free, a discussion is performed using the notes as a prompt. These notes should ensure that the developer can get needed details even if the tester is not around to maintain the momentum.

10.   After a user story completion, integration is performed as part of continuous integration and integration test cases are performed. Pair programmers have the responsibility for the continuous integration in the guidance of team leader.

11.   When all stories of sprint are complete then final UAT is performed, a backlog is created as collection of minor bugs. These are usually minor issues and take some minutes to resolve.

12.   When team is in mid sprint and a critical issue is encountered, it may require some scrum team members to resolve it.

a.      First thing we need to see whether it can wait until next sprint, as it may delay the current sprint release date and will change the scope of sprint. Another point is that developer should not feel that they are working in an environment where they need to switch gears in every five minutes. These are included as part of type backlog item.

b.      Sometime this issue is on top priority and can’t wait till next sprint. First thing we need to do that estimation of resolution with needed resources. Strategies are developed and after getting internal management buy-in, we need to present the situation to the client and strategy is discussed and approval is taken for the same.

Testing team is integral part of development and their collaboration is essential for the success of the project.

Seema Sonkiya