| HOME Software Testing Data Mining and Warehousing |
|
CASE STUDY 2: JWD CONSULTING'S PROJECT MANAGEMENT INTRANET SITE PROJECT (AGILE APPROACH) This section demonstrates a more agile approach to managing JWD Consulting's project management intranet site project. Instead of repeating the sample documents shown in the first, more predictive case study, this section emphasizes the differences of using an agile approach in each process group. Recall that an agile approach is often used for projects in which the business team cannot clearly express the scope early in the product life cycle, but the team does want to provide a potentially shippable product earlier rather than later. An agile project team typically uses several iterations or deliveries of software instead of waiting until the end of the project to provide one product. Note that teams do not normally make a snap decision about whether to manage a project using an agile approach or not. Likewise, you don't just decide whether to take a plane or a car on a long trip without specific logic. If you need to get somewhere quickly, have little concern for sightseeing along the way, and have no problems with flying, you will probably take a plane. If you want to take your time getting somewhere, see sights along the way, and enjoy driving, you will take a car. Likewise, organizations should use logic to decide when to use a more predictive approach or an agile approach to managing specific projects. Projects with heavy constraints, inexperienced and dispersed teams, large risks, generally clear up-front requirements, and a fairly rigid completion date are best done using a predictive approach. In contrast, projects with less rigid constraints, experienced and preferably co-located teams, smaller risks, unclear requirements, and more flexible scheduling would be more compatible with an agile approach. The same project is used in this text to highlight the main differences between the processes and outputs of these two approaches. When using agile techniques and its most popular method, Scrum, a team uses specific roles, artifacts, and ceremonies. Scrum Roles, Artifacts, and Ceremonies Recall from Section 2 that Scrum includes three main roles for project participants: • Product owner: The person responsible for the business value of the project and for deciding what work to do and in what order, as documented in the product backlog. In this case, Joe Fleming is the product owner. He is the CEO of JWD Consulting and the person who suggested the project. • ScrumMaster: The person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers that prevent the team from being effective. ScrumMasters have authority over the process but not the people on the team. They must be comfortable surrendering control to the product owner and team. Some experts suggest that traditional project managers do not make great Scrum Masters. In this case, Erica Bell will take on the challenge and serve as the ScrumMaster. • Scrum team or development team: A cross-functional team of five to nine people who organize themselves and the work to produce the desired results for each sprint. A sprint normally lasts two to four weeks, during which specific work must be completed and made ready for review. Large projects might require teams of teams. In this case, Michael Chen, Jessie Faue, Kevin Dodge, Cindy Dawson, Kim Phuong, and Page Miller are development team members. Their positions are listed in the project charter shown earlier in Table 6. Kim and Page are client representatives who do not work for JWD Consulting, but they are key team members, especially for developing the parts of the intranet that external clients would use. In Scrum, an artifact is a useful object created by people. An artifact can be called a deliverable in other project management approaches. The following three artifacts are created with Scrum: • Product backlog: A list of features prioritized by business value. The highest priority items should be broken down in enough detail for the team to estimate the effort involved in developing them. Some experts suggest scheduling about 10 workdays for each item. Of course, size and complexity of the work dictates the estimate. • Sprint backlog: The highest-priority items from the product backlog to be completed within a sprint. The Scrum team breaks down the highest-priority items into smaller tasks that take about 12 to 16 hours to complete. Examples of a sprint backlog and product backlog are provided later in this section under Planning. • Burndown chart: Shows the cumulative work remaining in a sprint on a day by-day basis. An example burndown chart is provided later in this section under Monitoring and Controlling. The ScrumMaster facilitates four ceremonies or meetings when using Scrum methods: • Sprint planning session: A meeting with the team to select a set of work from the product backlog to deliver during a sprint. This meeting takes about four hours to a full day. • Daily Scrum: A short meeting for the development team to share progress and challenges and plan work for the day. Ideally the team members are in the same place, the meeting usually lasts no more than 15 minutes, and it is held at the same time and place each day. If that is not possible, teams can use videoconferencing to have short virtual meetings. The ScrumMaster asks what work has been done since yesterday, what work is planned for today, and what impediments or stumbling blocks might hamper the team's efforts. The ScrumMaster documents these stumbling blocks and works with key stake holders to resolve them after the daily Scrum. Many teams use the term issues for items that do not have to be solved in the next 24 hours and blockers for items that need to be addressed immediately. This allows a ScrumMaster to maintain focus on highest-priority items (blockers) first and then manage the resolution of other issues over the next day or so. • Sprint reviews: A meeting in which the team demonstrates to the product owner what it has completed during the sprint. • Sprint retrospectives: A meeting in which the team looks for ways to improve the product and the process based on a review of the actual performance of the development team. FIG. 5 displays how you can view the Scrum framework shown in Section 2 in terms of the project management process groups. Creating the product backlog, developing the sprint backlog, and discussing plans during the daily Scrum would fall under planning. Performing the daily work and sprint, and creating the potentially shippable product increment would fit under executing. Holding the sprint review and discussing challenges as part of the daily Scrum can be viewed as monitoring and controlling. Reflecting during the sprint retrospective would fit under closing. Initiating the entire project is a phase that falls outside the Scrum framework in this example. Table 18 summarizes some of the unique Scrum activities by each process group. The following sections provide more detail on these activities.
============== Table 18 Unique Scrum activities by process group Initiating: • Determine roles • Decide how many sprints will compose each release and the scope of software to deliver Planning: • Create product backlog • Create sprint backlog • Create release backlog • Plan work each day in the daily Scrum • Document stumbling blocks in a list Executing: • Complete tasks each day during sprints • Produce a shippable product at the end of each sprint Monitoring and Controlling: • Resolve issues and blockers • Create and update burndown chart • Demonstrate the completed product during the sprint review meeting Closing: • Reflect on how to improve the product and process during the sprint reflection meeting ============= Project Pre-Initiation and Initiation The main differences between pre-initiation in this case and the first case would be deter mining roles and deciding what functionality will be delivered as part of each release, how many sprints will be required to complete a release, and how many releases of software to deliver, similar to dividing the project into several smaller projects. A project charter, stakeholder register, stakeholder management strategy, and kick-off meeting would still be created as part of initiation, just as they were in the first version of this case. Using the Scrum roles, however, Joe Fleming would be the product owner, Erica Bell the Scrum Master, and the other people listed in the project charter would be team members. Joe met with Erica to discuss what functionality will be delivered in each release, how many sprints will compose each release, how many software releases are required, and the approach required to complete the project. They decided that they still needed to survey potential users to collect requirements for the new software and determine a way to mea sure the value of the intranet site after it was implemented. They estimated that this work would take about two months. They thought that only a few tasks associated with the survey and benefits measurement could be included in the software being developed. For example, two new software features might collect user enhancement requests and collect project benefits information. Joe and Erica would work together to create a survey that specifically asks potential users of the new intranet site which features would provide the most value. For example, instead of listing general ideas, they would list specific features and have respondents rank them in order of importance. They would also ask survey respondents to submit sample templates, tools, and other useful information to Cindy Dawson, a project team member in the IT department. Collecting this information up front would streamline the software development process. Joe and Erica decided that three soft ware releases would be realistic, given the time and cost constraints. Each sprint would be targeted to last four weeks, and reviews and creation of the product and sprint backlogs would be an ongoing activity within each sprint. Joe and Erica had several meetings with Cindy and other team members. Cindy had the most experience working on agile projects. She discussed the importance of submitting several graphical user interface designs to prospective users to gain their feedback. This approach was extremely useful in the past, based on Cindy's experience, and it saves a lot of rework in development. For example, a team member would create one to four designs of a particular interface for prospective users to review in sessions hosted by a marketing team. The feedback helps lead to a better user interface that is more intuitive. Also, asking prospective users to rate the "look and feel" is very beneficial. Users may be distracted by a selected color scheme, for example, so team members should craft the same interface in various color schemes to gauge which one has the greatest appeal and generates the most positive "usability" score. Cindy explained that user interface designers are not normally development team members, but organizations might use them to provide detailed design specifications that provide a consistent user interface. Erica and Joe learned a lot from Cindy and would incorporate her recommendations into future plans. Planning Instead of creating a team contract, WBS, Gantt chart, and list of prioritized risks for the whole project, the team would follow the Scrum method. A preliminary scope statement for the entire project can still be a useful tool for planning; the team knows that more details will be added and changes will be made. Because Scrum implies that team members work as a self-directed group, coached by the ScrumMaster, a team contract should not be necessary. High-level descriptions of the work to be completed would be identified in the product and sprint backlogs. The team would develop a more detailed list of technical stories and associated tasks to complete during each sprint. The team must also establish a velocity (or capacity) estimate for each sprint based on team member availability each day of the sprint. Estimates can be provided as hours of work, assuming that all developers are contractors who can code eight hours per day, or they can be provided as points, assuming that developers are employees who code less than eight hours per day. For example, six hours per day would equal a point, so 36 hours of effort would equal 6 points. A Gantt chart for the entire project could still be created, as shown in FIG. 6. Notice that the process groups do not follow a simple linear pattern. Several process groups are repeated for each sprint, resulting in several iterations of a useful software product, as shown by the milestones. Recall that in the first version of this case, there was only one release or delivery of software near the end of the project, on October 17. In this case, two additional deliveries of software are scheduled on August 3 and September 11. Some teams create a release road map, as described later in this section, for each software delivery. The entire project is still scheduled for completion on November 1. FIG. 6 Intranet site project baseline Gantt chart using Scrum approach In addition to listing all of the preliminary project requirements in a scope statement, as shown in section 6.0 of Table 2, Joe, the product owner, created a product backlog to prioritize the most important functions of the new intranet software in terms of adding value to the business. Joe created the product backlog after analyzing the survey results and discussing options with several people. He included separate items for the most important templates and tools, instead of grouping them in one item, and requested a "point person" to contact for questions about each template or tool as well. Notice that this approach combined a few items in the scope statement shown in the first case to focus on what would add the most value. Having a point person would be useful before the team developed the more complex "Ask the Expert" feature. After reviewing the product back log, the Scrum team would do its planning to update the sprint backlog based on the items the team could complete in the first sprint. Table 19 provides an example of the product backlog and a sprint backlog for the first sprint. The team would then have its first daily Scrum meeting to plan the day. ============= Table 19 Product and sprint backlogs Product Backlog 1. User story templates, samples, and point person 2. WBS templates, samples, and point person 3. Project schedule templates, samples, and point person 4. Ability to charge customers for some intranet products and services 5. Ability to collect user suggestions 6. Business case templates, samples, and point person 7. Ask the Expert feature 8. Stakeholder management strategy templates, samples, and point person 9. Risk register templates, samples, and point person 10. Etc. Sprint Backlog 1. User story templates, samples, and point person 2. WBS templates, samples, and point person 3. Project schedule templates, samples, and point person 4. Ability to charge customers for some intranet products and services 5. Ability to collect user suggestions ============= The Scrum team would break down the items in the sprint backlog into more specific work items, often in the form of user stories, technical stories, and related tasks. User stories are short descriptions written by customers of what they need a system to do for them. These descriptions should be about three sentences long and provide the basis for time estimates for the sprint planning meeting. User stories should also be testable and small enough so that the programmers can complete and unit test their code in a timely manner. User stories are composed of technical stories. Technical stories are used by developers to translate user requirements into the technical specifications necessary to create the defined user functionality. The technical stories can contain one or more technical tasks that developers can use to chart progress on a sprint board as work is conducted through out a sprint. One item in the sprint backlog may or may not be documented in one user story, one technical story, and one task, based on its complexity. There could be a one to-one relationship or a many-to-one relationship if the item is highly complex. For example, someone in the finance area of the company should write a user story called "Ability to charge customers for some intranet products and services." It might read as follows: "As a financial manager, I want our site to use Company B to process payments so that we save money on transaction and customer service costs." User stories are broken down into a detailed technical story and then into tasks, similar to tasks in a work break down structure. See the companion Web site and other resources for more information on creating user stories and other planning documents when using a Scrum framework. Some organizations use a release road map to lay out all the work for an entire release, which can include more than one sprint. This road map is usually represented as a chart consisting of several columns. The release road map provides a clear picture of what stories (scope) will be contained in each sprint; velocity estimates versus actuals can be easily reviewed and updated. A release road map should be derived from data in the Project Management Information System (PMIS) or a related agile management system, such as Microsoft's Team Foundation Server, Rally, VersionOne, or JIRA. Executing As discussed earlier in this section, the most time and money should be spent on executing, where plans are implemented to create the desired product. The team would complete tasks each day, as it would in the first version of this case, but by using an agile approach, the team would produce several iterations of a potentially shippable product. For example, at the end of the first sprint, JWD Consulting would have some functionality available on its new project management intranet site. Users would be able to access templates, samples, and point persons for user stories, WBSs, and project schedules, as listed in the first sprint backlog. Users could also make suggestions for functionality they would like to see in the intranet site as it was being developed. The firstiterationofthesoftwarewouldalsoprovidetheabilitytochargecustomersforsome products and services. By using Scrum methods, the business could benefit from these new software features a few months earlier than they could using the approach described in the first case. Because Erica and some of the project team would be inexperienced in using Scrum, they would have to work out several challenges. For example, communications are very different because the project team meets every morning, physically or virtually. There would also be communications issues with users of the new intranet site, who might be confused by getting three iterations of the product instead of just one. See Sections 10 and 13, Project Communications Management and Project Stakeholder Management, for additional information. Monitoring and Controlling The two main items for monitoring and controlling in the Scrum framework are the daily Scrum and the sprint review. The daily Scrum includes a brief discussion of any issues and blockers the team is facing. The ScrumMaster would work with the appropriate stake holders to address these problems as part of monitoring and controlling. Removing obstacles so the team can perform well is one of the main job duties of the ScrumMaster. Daily Scrums are held each morning to plan and communicate work for the day and discuss any risks, issues, or blockers. The ScrumMaster documents these issues and blockers, similar to a list of prioritized risks. The work progress within a sprint can be represented on a sprint board maintained by the ScrumMaster. The sprint board contains cards that each represent a task to be worked on during the sprint. Each task card contains the control number, task name, estimate to complete, rank or priority number, and team member assigned. As tasks are opened, worked, and closed, they are moved physically to their appropriate section on the board. These sections include Not Started, In Progress, Ready to Test, Tested, and Closed. Developers will update the status of tasks in the Not Started, In Progress, and Ready to Test sections. Testers will update the status for tasks in the Tested section. The business owner should be responsible for reviewing functionality, confirming that it is working as expected, and changing a task's status to Closed. A burndown chart is an important artifact used to graphically display progress on each sprint (see FIG. 7). If the first sprint for the JWD Consulting intranet project is scheduled to last four weeks and produce five items or user stories listed in the sprint backlog, the burndown chart illustrates progress for that time period. Each user story should be broken down into specific tasks, and the team should estimate how long it will take to complete each task for each user story. A task should fit within a day, and the work a team member claims in the daily Scrum or stand-up meeting should fit within a day. Each day, the team should again estimate the number of hours remaining in each task. Some tasks might be added and some might be dropped as the scope becomes clearer. It does not matter how many hours are spent; what matters is how many hours of work remain to complete the user stories for that sprint. FIG. 7 Burndown chart The burndown chart plots each day's sum of estimated hours or points remaining. It also shows an idealized burndown line, as if the team were completing an equal amount of work each day, or 10 tasks each day in this example. The chart then clearly shows whether the team is doing well in that sprint or if there is potential for trouble. Burndown charts help the team understand whether user stories might not be completed within that sprint. If stories are at risk, the chart is an indicator that they should be removed. If progress is better than anticipated, the burndown chart can indicate that stories should be added to the sprint. At the end of each sprint, the ScrumMaster, or Erica in this example, leads the sprint demonstration review meeting. The team demonstrates to the product owner what it has completed during the sprint. In this case, Joe would review the five features created during the first sprint. After the sprint demonstration review, he would update the product back log based on the latest information and business needs, and the next sprint cycle would begin. Closing After the sprint review, the ScrumMaster leads a sprint retrospective. During this short meeting (about half an hour), the team reflects on what happened during the sprint. The ScrumMaster normally solicits team member feedback via e-mail first and collates these results before the meeting. This saves time and focuses the discussion on items that are most important. The retrospective is similar to a lessons-learned report, but it focuses on a shorter period of time. The sprint retrospective is intended to answer two fundamental questions: • What went well during the last sprint that we should continue doing? • What could we do differently to improve the product or process? The sprint retrospective meeting is usually led by the ScrumMaster, who documents a list of action items for implementation. Those items may be added to the product backlog if the product owner agrees with them. For example, after the first sprint for the JWD project management intranet site project, the team might suggest that the site be mobile enabled. This new requirement could be added to the product backlog and selected as an item for the next sprint. Recall that an agile approach welcomes new requirements as long as they focus on business value. As demonstrated in reviewing the two approaches to the same project, the agile approach has similarities and differences compared with the traditional approach. If done well, an agile method can produce several iterations of useful software. This approach allows the organization to work together quickly to address changing business needs. Templates by Process Group As you can see, project teams prepare many documents throughout the life of a project. Many people use templates as a standard format for preparing those documents. Table3-20liststemplatesusedtoprepare the documents shown in this section and later sections. The table lists the template name, section number, process group(s) in which you normally use the template, the application software used to create it, and the file name for the template. Feel free to modify the templates to meet your needs. The project management process groups-initiating, planning, executing, monitoring and controlling, and closing-provide a useful framework for understanding project management. They apply to most projects, both IT and non-IT, and along with the project management knowledge areas, help project managers see the big picture of managing a project in their organization. Table 20 Templates by process group ============== CASE WRAP-UP Erica Bell and her team finished the project management intranet site project on November 4, as planned in their project charter. They did go over budget, but Joe had approved Erica's request for additional funds, primarily for purchasing external software and customization. Like any project, they had a few challenges, but they worked together as a team and used good project management to meet their sponsor's and users' needs. They received positive initial feedback from internal consultants and some of their clients on the new intranet site. People were asking for templates, examples, and expert advice even before the system was ready. About a year after the project was completed, Erica worked with a member of the Finance department to review the benefits of the new system. The Project Management Office did lose one of its staff members, but it did not request a replacement because the new system helped reduce the PMO's workload. This saved the firm about $70,000 a year for the salary and benefits of that staff position. The team also had data to show that the firm saved more than $180,000 on contracts with clients because of the new system, compared with their projection of $160,000. The firm was breaking even with the "Ask the Expert" feature during the first year, and Erica estimated that the system provided $30,000 in additional profits the first year by generating new business, instead of the $40,000 the team had projected. However, savings from the PMO staff position salary and the extra savings on contracts more than made up for the $10,000 difference. Joe was proud of the project team and the system they produced to help make JWD Consulting a world-class organization. =============== Summary Project management involves a number of interlinked processes. The five project management process groups are initiating, planning, executing, monitoring and controlling, and closing. These processes occur at varying levels of intensity throughout each phase of a project, and specific outcomes are produced as a result of each process. Normally the executing processes require the most resources and time, followed by the planning processes. Mapping the main activities of each project management process group into the 10 project management knowledge areas provides a big picture of what activities are involved in project management. Some organizations develop their own IT project management methodologies, often using the standards in the PMBOK® Guide as a foundation. It is important to tailor project management methodologies to meet the organization's particular needs. Popular methods like PRINCE2, Agile, RUP, and Six Sigma include project management processes. The JWD Consulting case study demonstrates how one organization managed an IT project from start to finish. The case study provides several samples of outputs produced for initiating, planning, executing, monitoring and controlling, and closing: • Business case • Stakeholder register • Stakeholder management strategy • Project charter • Kick-off meeting agenda • Team contract • Work breakdown structure • Gantt chart • List of prioritized risks • Milestone report • Progress report • Lessons-learned report • Final project report The second version of the same case study illustrates how to use Scrum, the leading agile method, to manage the project. Instead of releasing the new intranet software just once near the end of the project, the team could release three iterations of the software. This version of the case study introduced some new tools, including a product backlog, sprint backlog, and burn down chart. Later sections in this text provide detailed information for creating these and other project management documents and using several of the tools and techniques described in both versions of this case study. Quiz 1. A ______ is a series of actions directed toward a particular result. a. goal b. process c. plan d. project 2. ______ processes include coordinating people and other resources to carry out project plans and create the products, services, or results of the project or phase. a. Initiating b. Planning c. Executing d. Monitoring and controlling e. Closing 3. Which process group normally requires the most resources and time? a. Initiating b. Planning c. Executing d. Monitoring and controlling e. Closing 4. What methodology was developed in the United Kingdom, defines 45 separate subprocesses, and organizes them into eight process groups? a. Six Sigma b. RUP c. PMBOK® Guide d. PRINCE2 5. Which of the following outputs is often completed before initiating a project? a. stakeholder register b. business case c. project charter d. kick-off meeting 6. A work breakdown structure, project schedule, and cost estimates are outputs of the ______ process. a. initiating b. planning c. executing d. monitoring and controlling e. closing 7. Initiating involves developing a project charter, which is part of the project ______ management knowledge area. a. integration b. scope c. communications d. risk 8. ______ involves measuring progress toward project objectives and taking corrective actions. a. Initiating b. Planning c. Executing d. Monitoring and controlling e. Closing 9. Which of the following is not a typical reason that project teams would use a predictive approach versus an agile approach to managing a project? a. The project has unclear up-front requirements. b. The project team is inexperienced and dispersed. c. Large risks are involved. d. The completion date is fairly rigid. 10. Many people use ______ to have a standard format for preparing various project management documents. a. methodologies b. templates c. project management software d. standards Answers 1. b; 2. c; 3. c; 4. d; 5. b; 6. b; 7. a; 8. d; 9. a; 10. b Discussion Questions 1. Briefly describe what happens in each of the five project management process groups (initiating, planning, executing, monitoring and controlling, and closing). What types of activities occur before initiating a project? 2. Approximately how much time do good project managers spend on each process group, and why? 3. Why do organizations need to tailor project management concepts, such as those found in the PMBOK Guide, to create their own methodologies? 4. What are some of the key outputs of each process group? 5. What are some of the typical challenges project teams face during each of the five process groups? You can frame your discussion based on a project described in one of the feature boxes in this section (for example, the What Went Right? or What Went Wrong? feature). You can also frame your discussion on one of PMI's Project of the Year Award winners, or on a well-known project failure like the Denver International Airport baggage handling system. 6. What are the main differences between the two versions of the JWD Consulting case study? When should you use a more prescriptive or agile approach? Do you think users of the JWD Consulting Intranet site would prefer one release of the software or several incremental ones? What are some pros and cons of each approach? Exercises 1. Study the WBS and Gantt charts provided in Figures 3-3 and 3-4. Enter the WBS into Project 2010, indenting tasks as shown to create the WBS hierarchy. Do not enter durations or dependencies. Print the resulting Gantt chart. See the scope management section of section A for help using Project 2010. 2. Read William Munroe's article about Blue Cross Blue Shield of Michigan's IT project management methodology, which is available on the companion Web site for this text under Section 3. Or, research another method, such as PRINCE2, Agile, RUP, or Six Sigma, and how organizations use it, citing at least two references. Why do you think organizations spend time and money tailoring a methodology to their environment? Write a summary of your findings and your opinion on the topic. 3. Read the "ResNet Case Study," which is available from the companion Web site for this text under Section 3. This real case study about Northwest Airlines' reservation system illustrates another application of the project management process groups. Write a paper summarizing the main outputs produced during each project process group in this case. Also, include your opinion of whether Peeter Kivestu was an effective project manager. If you prefer, find another well-documented project and summarize it instead. 4. JWD Consulting wrote a business case before officially initiating the project management intranet site project. Review the contents of this document in Table 2 and find two articles that describe the need to justify investing in IT projects. In addition, describe whether you think most projects should include a business case before the project sponsors officially approve the project. Write a short paper summarizing your findings and opinions. 5. Read an article or watch a video about a recipient of PMI's Project of the Year award. Search for information online or consult the link on the text's companion Web site for more information. Past winners of the award include Prairie Waters Project, National Ignition Facility Project, and Newmont TS Power Plan Project. Write a one-page paper summarizing a winning project, focusing on how the project manager and team used good project management practices. 6. Review the product backlog, sprint backlog, and burndown chart provided in this section. Read articles or watch a video about using a Scrum method that mentions these artifacts. Write a short paper that describes more details about how to create these artifacts; cite at least two references. 7. You are a project consultant for the ACME Company and are helping to develop an agile method using Scrum. The company has always used predictive project management methods for software development, but company managers have heard that Agile can have significant advantages if implemented properly. Prepare a proposal that suggests what training, documentation, executive support, and team management approaches are needed to start a pilot for Agile. Provide justification for your recommendations. 8. Download the template files used in this text. Review several of the files, and look at examples of how they are used in this text. Also search the Internet for other template files. Write a short paper to summarize what you think about using templates and how you think they can help project managers and their teams. Also discuss potential problems with using templates. Terminology
|
| Top of Page | More PM Articles | Prev. | Next | Info-Source.us |
