Create a scrum board in Microsoft® Excel® format similar to the linked example. The scrum board you create should align with the project charter you created in the Week 2 Project Charter learning team assignment. Be sure your finished scrum board incorporates a project budget.

CMGT 410 Week 1 Project Plan Draft

A project plan is a document created at the beginning of the project lifecycle that gives stakeholders and everyone else involved in a project a clear idea of what a project will entail in terms of effort, time, cost, and anticipated results.

One of the things that must be identified before the project plan can be created is the methodology, or approach, the project manager plans to use to manage the project. Choosing a methodology is important because a methodology provides the framework—that is, an overall process and suggested documents and deliverables—that will guide project development from beginning to end. Some project methodologies are more appropriate for some types of projects than for others.

For this assignment, you will:

1. Choose a project methodology for two different projects based on project requirements, and explain why you chose each methodology for each project.

2. Brainstorm your own project and create a draft simplified project plan for that project. You must indicate in your simplified project plan whether you intend to apply the Agile or waterfall methodology. You may create your simplified project plan using Microsoft® Excel® or, if you choose, another software application such as Microsoft® Project®.

To complete this assignment:

Read  Agile Project Management and the PMBOK® Guide .

Answer the Methodology Selection and Rationale questions.

Brainstorm a project you would like to explore in this course. You may choose a project from your work experience, from a description of a project in your textbook or in an online reading, or a project that is brand new but that you think would improve a business process at work, at home, or at school.

Read the two linked examples of project plans implemented as Microsoft® Excel® spreadsheets, Example Plan A and Example Plan B. You will be using these as guides in creating your own draft project plan. Notice especially the differences between these two examples in terms of length (overall and task length), structure of the work breakdown (iterative vs. non-iterative), and methodology.

Research additional project plan examples online.

Create a simplified project plan for your own brainstormed project that resembles the two linked examples.

Save your simplified project plan as a Microsoft® Excel® spreadsheet document.

Submit both your completed Methodology Selection and Rationale questions and your project plan draft (Microsoft® Excel® document).

CMGT 410 Week 2 Documenting the Project Lifecycle

Well-written project documentation clarifies intent, documents decisions and results, and allows project managers to assess project progress (and report it, as necessary, to project stakeholders) at every step of the project lifecycle.

For this assignment, you will create two examples of project documentation that align with the Project Plan Draft assignment you completed in Week 1. The documentation you will create for this assignment aligns with the initiation and planning phases of a project.

If you chose the waterfall methodology for your Week 1 Project Plan Draft assignment, create the following:

· A business requirements document, or BRD: Use the Business Requirements Template as the basis for your BRD.

· A work breakdown schedule, or WBS: Use the Work Breakdown Structure (WBS) Example document as the basis for your WBS.

Alternatively, if you chose the Agile methodology for your Week 1 Project Plan Draft assignment, create the following:

· A product requirements document, or PRD: Read “Product Requirements Documents, Downsized” for assistance in creating this document.

· User stories/scenarios and acceptance criteria: Review “Agile Requirements Snail: Feature to User Story to Scenario” for help in creating this document. Then use the Scenarios and COS tabs located in User Scenarios And Acceptance Criteria Example as the basis for your user stories/scenarios and acceptance criteria.

Submit your completed BRD and WBS, or your completed PRD and user stories/scenarios with acceptance criteria.

CMGT 410 Week 3 Create a Scrum Board

Projects that conform to the Agile methodology often use something called a scrum board. You can think of a scrum board as a digital whiteboard containing yellow “stickies,” each listing a task, posted beneath categories such as “to do,” “in process,” in testing,” and so forth. Using a scrum board in this way allows all project members to see where important tasks are in the overall project process quickly and easily.

For this learning team assignment, you will collaborate with your team members to create an Agile scrum board based on the project charter you created with your team in Week 2.

Note that in an industry situation, you would most likely use a specialized software tool to manage your scrum board such as Jira, Rally, Asana, or Basecamp. However, in this course, you will be using a tool that you may already be familiar with—Microsoft® Excel®—to create your scrum board and other deliverables. It is the organization and assignment of tasks that is important about a scrum board, not the specific software tool you use to create and manage the scrum board.

To complete this learning team assignment:

Review the Learning Team Scrum Board Example spreadsheet. (Note: Click the Board tab that appears at the bottom of the spreadsheet to see the scrum board example.)

Create a scrum board in Microsoft® Excel® format similar to the linked example. The scrum board you create should align with the project charter you created in the Week 2 Project Charter learning team assignment. Be sure your finished scrum board incorporates a project budget.

Submit the team assignment.

CMGT 410 Week 3 Project Scheduling and Documentation

One of the most important documents in a project is the kickoff presentation. Because this document formally begins, or “kicks off,” project development, it can only be created after the project has been planned, approvals have been obtained, and personnel are in place. A good kickoff presentation communicates succinctly to all attendees what needs to be accomplished to complete the project, in what order, and by whom. It sets expectations and, ideally, energizes project team members. The desired outcome of a project kickoff presentation is for team members to begin tackling the first defined project tasks and know whom to contact if they encounter delays.

For this assignment, you will create a kickoff presentation in Microsoft® PowerPoint® based on the draft project plan you created in the Week 1 Project Plan Draft individual assignment.

To complete this assignment:

Review the “Kickoff Presentation” section in Ch. 9, “Communication; Project Communication Strategy; from Project Kickoff to Daily Meetings,” of The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond.

Create an 8- to 9-slide project kickoff presentation in Microsoft® PowerPoint® similar to this Project Kickoff sample template. The kickoff presentation you create should include details pertaining to the project you defined in the Week 1 Project Plan Draft assignment, including budget details as appropriate. Specifically, your presentation should include:

· A high-level project definition

· Business case (a description of the business problem/opportunity the plan is designed to solve/exploit)

· Project approach

· Description of team members and roles

· Project scope

· Out of scope

· Timeline

· Budget and budget reporting

· Risks, cautions, and disclaimers

Submit your completed project kickoff presentation.

CMGT 410 Week 4 H
andling a Project Crisis

You are a project manager. During testing, a business user identifies a problem: the tested version lacks a fundamental capability that, as it turns out, was never identified. This capability does not just represent a nice-to-have feature; it is integral to the IT deliverable functioning in the real world. You comb through your project management software, old emails, and meeting agendas, but you cannot find the functionality documented anywhere.

As you dig into the problem, you realize that the new functionality the business user is asking for cannot be delivered given the underlying technology that was chosen for this project. The relational database identified in the project plan is simply too slow in reporting and data transfer to support the new functionality.

You discuss the problem with the project architect, who suggests two alternatives:

1. Tune the relational data queries and upgrade the relational database server.

2. Move all of the data from the relational database to a Big Data repository, such as Hadoop.

As project manager, your task is to write a memo to the project sponsor in which you:

· Succinctly outline the problem identified

· Describe the two alternatives listed above

· Articulate the cost of each alternative in terms of its impact to the schedule, cost, and functionality of the final deliverables

· Recommend one alternative over the other based on those costs and schedule impacts

To complete this assignment:

Read the following articles to familiarize yourself with some of the differences between Big Data repositories and relational database management systems:

· “NoSQL and Hadoop: Document-Based versus Relational Databases“

· “What is Apache Hadoop?”

Write a 2- to 3-page memo that meets the requirements described above.

Cite any sources you include in APA format.

Save your work as a Microsoft® Word document.

Submit your assignment.

CMGT 410 Week 5 User Acceptance Testing

User acceptance testing, or UAT, is a round of testing in which the users who are expected to use the system after it goes live exercise the system. UAT differs from quality assurance, or QA, testing in a very important way: In UAT, real users attempt to use the system-in-development in a realistic manner—that is, the way they plan to use it after it goes live. In QA, technical people (who may or may not be familiar with how the system is actually going to be used in a business setting) exercise specific bits of functionality. Because of this difference in approach, UAT often exposes bugs that were not caught in QA. In addition, UAT allows users to feel confident that the system will work as they expect it to once it has been implemented, and to signal this confidence formally by signing off on the UAT.

For this assignment, you will work with your team members to build a User Acceptance Test Plan for the team project (system) you defined collaboratively in Weeks 2 and 3.

As part of this plan, you will create acceptance criteria for all user stories/scenarios associated with this project. In other words, you will collectively generate user stories/scenarios (i.e., brainstorm how users can reasonably be expected to use the system you defined) and then define each of the user stories/scenarios you list as a bug, a function not working as expected, a request for improvement, or a feature request.

To complete this assignment:

Read “Acceptance Criteria in Scrum: Explanation, Examples, and Template.”

Review the following sections of Ch. 13, “Launch and Post-Launch: UAT, Security Testing, Performance Testing, Go Live, Rollback Criteria, and Support Mode,” in The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond:

· “User Acceptance Testing: What It Is and When It Happens”

· “Controlling UAT and ‘We Talked About It in a Meeting Once,’ Part Deux”

· “Classifying UAT Feedback”

· “Bugs”

· “Not Working as Expected – The Trickiest Category”

· “Request for Improvement”

· “Feature Request”

· “Conflict Resolution and Final Launch List”

As a group, complete the COS sheet portion of the linked UAT Plan Template. Note: Click the COS tab that appears at the bottom of the spreadsheet to see the COS sheet. COS stands for Conditions of Satisfaction/Acceptance Criteria.

Save your collaboratively completed UAT plan template using a unique file name that does not include the string “Template”.

Submit the team assignment.

CMGT 410 Week 5 Bugs vs. Feature Requests

There is no such thing as a bug-free IT project. Because bugs are a fact of IT project life, IT project managers must articulate a process for identifying, tracking, and handling the bugs that will inevitably occur. In addition, because technical and business requirements change frequently, IT project managers must also plan to log and track requests for new features and functionality.

Read the following linked documents:

· “Visual Studio – Manage Bugs“: This article describes the process of tracking bugs in Visual Studio, a popular .NET development suite created by Microsoft®.

· “What Is a Bug and Issue Tracking Tool?“: This article describes the process of tracking bugs in Jira, a popular bug tracking and project management tool created by Atlassian.

Create a 3-page Microsoft® Word document of a bug tracking process for the project you created in the individual assignments in Weeks 2 and 3. Be sure to differentiate between bugs and feature requests. For this assignment, you will only be tracking bugs.

Your tracking process must include:

· Description of software you propose using for bug tracking (in-house developed or third-party)

· Description of issues that will be considered bugs (vs. feature requests)

· Description of who will use the system to track bugs

· Description of who will monitor the system, follow up with the requestor as necessary, and implement the bug fixes

· Description of bug-related information (such as a unique tracking number, description, assignee, etc.) necessary to identify, fix, and log bugs

Submit your completed document.

Previous answers to this question

---

Get The Answer