Is the schedule driving the project or vice versa
ACE Blog Article Home Is the schedule driving the project or vice versa Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? Share This Story, Choose Your Platform! Is the schedule driving the project or vice versa? Note: This article was first published on Knowledge Hut Blog, our blog partner. Are you familiar with a situation where a project manager diligently drafts a project schedule and uses it to drive the project for 2-3 weeks and then the schedule goes into cold storage? Either the schedule disappears or gets driven by the project getting executed independent of the schedule. Most people that I interact with tell me that this is a very common scenario. Why does this happen? How can it be avoided and how can we draft an effective schedule that can actually be used to drive the project till its completion? What are the characteristics of such an effective schedule? Why should a project manager take pains to draw up such an effective schedule and what are the benefits? We have done some research in this area by studying a number of real project schedules and would like to present the findings in this article. Why effective schedules are important? One of the major challenges faced by the software industry is delivering fixed price projects profitably. And poor scheduling is one of the top three areas of challenge, the other two being poor estimates and poor requirements management. While leading a delivery excellence program, I happened to interview several roles and one business unit head revealed that he had won a million dollar deal recently and assigned the best PM of the BU to the project. And when that PM came up with a draft schedule, it had a built-in overrun of 5%. Projects typically follow the Murphy’s law “work expands to fill duration” and people tend to consume all of the allocated duration, even if it is in excess, and on top of the built-in 5% overrun, if there is an additional 20% overrun, then the project would move into a loss zone. Incidentally, the BU head was a pro in scheduling, he sat with the PM, optimized resource allocation and then the schedule came down to utilize only 85% of the originally estimated effort. Mind you, this schedule did not reduce the effort or duration of individual tasks but just carried out resource optimization and boom, the effort reduces by 20%!! This incident highlights that well drafted schedules can play a major role in profitability of fixed price projects. And the ROI can also be huge as spending ½ a day in scrutinizing the schedule lead to a saving of almost two hundred thousand dollars in this case. What makes schedules unusable? Why do schedules go into cold storage in spite of their critical advantages? Because, these schedule are not usable. What makes schedules unusable? Having researched into dozens of schedules, we have found several common factors that make schedules unusable and the top three reasons are explained below. The task breakdown does not match with the actual tasks that will be performed to realize the end deliverables: Many PMs would be out of touch with software engineering and cannot figure out what activities will be performed and what artifacts will be produced in each phase of the project at a granular level. They may be familiar at a coarse level that analysis, design, coding and testing will be performed but they may not be able to determine exactly what tasks constitute analysis and design and what artifacts will be produced from these tasks. For instance, they may not be identify all the activities and artifacts such as “Design object model”, “Normalize database”, “Create interaction diagrams” that results respectively in object model, database model and interaction diagrams all of them becoming a part of design document. As a result, PM may not be able to document all the tasks in the schedule and the team will be performing many tasks, not accounted for in the schedule. This gap quickly causes misalignment between schedule and actual work. Consequentially, the team stops referring to the schedule for guidance on what to do and the schedule becomes unusable. Estimated duration in the schedule does not match original effort estimates: Many PMs allocate duration to tasks independently instead of deriving them from the original effort estimates. They may not follow any formal method while estimating durations and this makes dates in the schedule mismatch with the actual dates significantly. Although, even the well-drafted, usable schedules can also have mismatch between planned and actual dates, a large-scale mismatch may discourage the team members to use the schedule as a guidance to determine their weekly plan. Resource loading is not optimal: The resources are either under-loaded or overloaded. When the resources are under-loaded, the Murphy’s law “Work expands to fill duration” may kick in and the under-loaded resources may use up all of the available duration (allocated duration and free time) to perform the allocated work resulting in effort and schedule overruns. The overloaded resources obviously cannot perform work according to the schedule and they start performing work independent of the schedule. What makes schedules usable? Having seen the characteristics of unusable schedules, we have also seen the characteristics of usable schedules. It is not necessary that usable schedules are lax schedules. Very tight schedules can also be well-drafted and usable schedules. Our research into schedules that have been successfully used to drive and track projects from inception till end shows that they generally possess a large number of following characteristics. Work breakdown is immaculate The structure of the work breakdown is completely aligned with the software engineering life cycle chosen for the project The WBS covers at least 90% of all activities that will be performed in the project. The amount of time that people spend doing
Essential project management other than PMI
ACE Blog Article Home Essential Software project management skills other than PMI Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts IT trends: Will the Indian IT industry survive through the smart app explosion? Comparing strategic and tactical outsourcing Requirement change management by leveraging project constraints Is the schedule driving the project or vice versa What the CMMi and PMBoK don't tell you How can we help you? Send Essential Software project management skills other than PMI September 7th, 2015 Posted by: admin Project management skills and competencies needed to be possessed by software project managers is an interesting topic. The project management skills can be divided into two categories – core project management skills and interpersonal skills (or soft skills). The Project Management Body of Knowledge (PMBoK) published by PMI (Project Management Institute) details out the subject areas of core project management skills needed for project managers. When this is so, why this article? Well, the PMBoK does not go into the specifics of software project management and software project managers need skills beyond what is detailed out in PMBoK and this article is about this set of additional skills needed for software project managers Why PMBoK is inadequate for software project management? PMBoK is a very good generalisation of core project management knowledge needed to be possessed by project managers. However, it falls short in the following situations Effort estimation:Software project managers need to be aware of specific software estimation methodologies not covered by PMBoK to ensure accurate estimates. Requirement modelling: Documenting requirements and scope properly is critical to project success. Even though a PM need not carry out the documentation by himself, he needs to ensure that the documentation is done to a required degree of clarity and completeness. This needs some working knowledge of requirements modelling techniques such as ER diagrams, object modelling, use cases and so on, though not an in-depth understanding. Project scheduling: Application of scheduling techniques to software projects using tools such as MS Project Software life cycles: A project manager needs to understand what tasks constitutes the complete project and the task breakdown would be based on the life cycle model being followed. PMBoK only touches the project life cycles and a software PM needs an in depth understanding of the ‘V’ process model, Rational Unified Process, Iterative and Incremental models, Scrum and XP models and so on. Software test management: A project manager should be able to make the right decisions such as whether to continue testing, or carry out a root cause analysis or carry out a partial re-design etc. depending on the intermediate test results. This requires knowledge of characteristics of software quality. Thus, it is evident that a significant additional body of knowledge is required for a PMP certified person to become an effective software project manager The list of skills Based on the above analysis, following is a list of core software project management skills that a software PM needs to possess in addition to PMBoK and interpersonal skills. Ability to organise requirements elicitation workshops resulting in clarity and completeness of requirements Ability to bring the 3 parties – stakeholders, analysts and developers on the same page about what constitutes requirements. The PM needs to ensure clear and adequate documentation of requirements with proper models and needs some working knowledge of requirement modelling and documentation techniques. Requirements management – Ability to anticipate changes, impose change management discipline, avoid scope creep and groom product backlog if using Agile methods. Estimation methodologies – Ability to ensure accurate estimates through use of an appropriate software effort estimation methodology Project planning and tracking – Integrated project planning and tracking with a clear understanding of project dimensions and execution methodology based on life cycle models. Software test management – Knowledge of software testing and decision making during testing phase Project scheduling – Ability to draw up usable schedules using tools such as MS Project and use the schedule to regularly drive the project and track it.
Do you convey WIIFM while assigning roles to team members?
ACE Blog Article Home Do you convey WIIFM while assigning roles to team members? Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? Do you convey WIIFM while assigning roles to team members? September 7th, 2015 Posted by: admin Do you convey WIIFM for motivating team? Why WIIFM? Have you come across situations where the team members lack ownership of tasks assigned to them? And because of lack of ownership, does the project manager have to Follow-up frequently? Provide instructions and guidelines on issues that team members are expected to understand and execute by themselves? Motivate them frequently? Well, if this is the case, there is a good chance that the WIIFM for the team members is being ignored while assigning their roles and responsibilities. WIIFM stands for What’s In It For Me and answering WIIFM is a wide practice in mature organizations to ensure that employees own the responsibilities that they take up. What is WIIFM? Professionals work for many motives – money, designation (reputation), job satisfaction, a penchant for delivering results, networking, diving deep into technology, developing knowledge such as process knowledge & domain knowledge, growth in chosen career path etc. While an average expected salary level is common for everybody, additional incentives can be quite motivating for some but not for all. This additional incentive is what we mean by money as a factor of motivation. Other motivational factors are self-explanatory. While allocating roles and responsibilities, it helps if the project manager relates the role and responsibility to the career aspiration of the team member. That is, the question – ‘What’s In It For Me if I take up this role?’ has to be answered for the team member. If this is done, the team member is most likely to develop ownership of his role and is more likely to be happy to go the extra mile to deliver results. This insight may appear to be common sense; however, practicing it is quite tricky as it can backfire if not implemented cautiously. Therefore, analysing the tricky nature of WIIFM and illustrating simple ways of practicing it with real life examples is the purpose of this article. Digging deeper into WIIFM If there is ownership, the team members would not wait for instructions and would travel the extra mile to deliver the results. On the contrary if the team member lacks ownership, s/he would develop a distance with his/her work and this would not only result in reduced productivity, but also in other consequences such as not being self-driven, not figuring out certain details by themselves etc. Therefore, it is important to ensure that team members own their work and not develop a distance with it. This is better illustrated with an experiment. An interesting experiment that I have come across in team building exercises is as follows: A weighty object, typically a big stone is kept and a boundary strip is marked next to the stone. Workshop participants have to stand outside the boundary strip, lift the stone and hold it in air as long as they can. Depending on the weight of the stone, either many participants fail to lift the stone or even if they lift, they won’t be able to hold it for long. This happens because they are lifting the stone from a distance due to the boundary strip and it requires more energy to lift the stone from a distance. In the next step, the boundary strip is removed and participants are allowed to stand close to the stone and lift it. In this attempt, most will be able to lift the stone and hold it much longer than they could, during the first attempt. Moral of the experiment is that when there is a distance between the task and the performer, execution of the task becomes more tedious. This physical illustration holds true in the emotional sphere also. If an employee doesn’t feel that the work that he is carrying out belongs to him, then he would find it tedious. It is because of this tediousness that quality suffers and it takes more time to deliver. WIIFM would come to the rescue here. Using WIIFM for motivating team in simple ways Dealing with WIIFM can be quite tricky as it can be counter-productive at times. When the team members’ aspirations are captured, it raises their expectation bar and if there is no attempt to fulfil the aspirations, it can lead to disheartenment and further lack of ownership. On the other hand meeting the aspirations as-is can also be quite challenging as it may infeasible, or unjustified or may be against company policy. Some may be expecting a fast promotion and may not yet deserve; giving them promotion raises the expectation bar of others and can be counter-productive on the others. Some may be expecting a salary increment that may be disproportionate to what they deserve and it may be over and above the company policies. So, meeting the aspirations as-is could also troublesome. Therefore, the best way out is to meet the aspirations in a judicious and balanced way. After capturing the aspirations of the team member, the project manager has to think about them honestly and try to meet the aspirations to the extent possible within the project context. Two anecdotes below illustrate simple and pragmatic ways in which WIIFM of team members have been fulfilled – The project involved a legacy application based on IBM AS 400 and the project manager did carry out simple one-on-one meetings with the team members during the project initiation. One of the star performers of the project expressed that he is interested in Java and not in AS 400 technology. When asked by the project manager as to why he is specific about Java, the team member answered that Java projects are technologically more challenging and handling more challenging