General Archive

0

Responsibility Assignment Matrix

As a graphical depiction of a more detailed perspective of responsibilities, the responsibility assignment matrix should reflect assigned responsibility by functional role for key project deliverables.  An example of roles detailed below could include (1) Project Manager, (2) Project Sponsor, (3) Implementation Manager, (N) Team Lead

Project Deliverables Role 1 Role 2 Role 3 Role N
WBS 1.15.10.1300 – Project Charter E A C I
WBS 1.15.10.1301 – Project Schedule E A,C A I
WBS 1.15.10.1302 – Project Budget E A,C E I
WBS 1.15.10.1303 – Status Reports C C A E
Legend
E = responsible for execution (may be shared)
A = final approval for authority
C = must be consulted
I = must be informed

I use this matrix in a few of my project artifacts, to include the Lessons Learned.
You can download a free copy here

Popularity: 1%

0

Contribute for the better good

Scrum OverviewI just posted an update to the Agile Scrum definition on Wikipedia. It has been a while since I’ve made updates to this definition and others on the free online encyclopedia.  It’s actually quite cathartic to contribute to something like Wikipedia, for no other reason then to help others.  I’ve been asked a lot of questions recently about Agile Scrum and its applicability to my current project.  Though I’m happy that people value my opinion, I figured it was time I revisited Wikipedia and make sure the items I’ve edited in the past still pass muster.  Sure enough, without telling anyone that I am one of the contributors, I’ve received two  emails linking to the Wikipedia definitions with notes like “You should check this out”.   I hope by continuing to make contributions and updates to publicly available PM related topics, people will be exposed to my work if they know it or not.

Have a great day and feel free to leave a comment!

Regards,
Derek

(Image by drewpreston on flickr)

Popularity: 1%

0

Understanding Agile Scrum and common terms

I’ve been in a few meetings this last week where people were mentioning Scrum terms but didn’t know what they were. It’s not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I’ve seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted “something” within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it’s important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner
The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director…  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster
The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team
A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering…)  This team traditionally sits in the same room or area.

Scrum Team
Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart
Daily progress for a Sprint over the sprint’s duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog
A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you’d find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog
A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint
A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product
An output requested by the customer.  It is a completed document, process, web page, database…  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post:
Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories

Popularity: 1%

4

Free Lessons Learned Template

It is not important that you call it a Lessons Learned or a Postmortem. What is important is you learn from your mistakes. At the end of every iteration or project, you should identify everything that went wrong or could have gone better. Articulate them in a document. At the beginning of each new iteration or project, review the document and see not only what was learned but what has been implemented. Feel free to download my free Lessons Learned [Template]

Popularity: 8%

4

Applicable quote to Earned Value Management

While I was doing some research for my book, I came across an excellent quote by Bill Hewlett.  Do you think your boss understands this quote?

“You cannot manage what you cannot measure…and what gets measured gets done.”
— Bill Hewlett, Hewlett Packard

Popularity: 1%

Tags: , , ,