Skip to main content
  • 3829 Accesses

Abstract

In the previous chapter, we saw how and why the portfolio team selected the project. It ended with a project manager being assigned to move the project forward, guided by the project charter. Before the actual product construction gets underway, some preparatory work is necessary, which is critical to cultivating the fertile ground for both the business and technical team and sowing a good working partnership between them.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 34.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 44.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    Here artifact is used as a key document that informs later parts of the project, or members of the project. Interim or working documents are also created, used somewhat like a scratchpad, and discarded, so are not considered artifacts.

  2. 2.

    Agile organizations prefer that an agile team is always in place for forthcoming projects, and work is brought to the team instead of, as is often the case, forming teams around new projects then disbanding them after the project. This book is about PMs trying agile techniques in organizations that have not yet completely embraced all agile practices, so I assume, as a worst case, that new teams are formed for each project.

  3. 3.

    There is an even worse relationship: when the business units duplicate the information technology (IT) services and resources within their own units so that they bypass IT. The business units hire their own software staff to act as “personal programmers” on the whim of the upper management. This kind of fragmentation and vote-of-no-confidence for IT leads to a breakdown in the economies of scale that justifies a centralized IT relationship in the first place.

  4. 4.

    The RAM is a general term, more commonly known as a RACI chart, for Responsible, Accountable, Contributing, and Informed. I think that the alternative CORA is more self-evident as to who does what in a role.

  5. 5.

    If the project uses the SCRUM agile variation of a single product owner, the PM does not need to write a communication plan because it falls to the PO to manage the stakeholders’ expectations.

  6. 6.

    The technical team kickoff meeting is done as part of Iteration 0, but all comments apply to that meeting too.

  7. 7.

    A feature is a rather amorphously defined aspect of the product that contains value to the customer. It is similar to the checklist of items advertised on the back of many product packages.

  8. 8.

    Rough-order-of-magnitude estimate

  9. 9.

    “Ideal days” and “ideal hours” are actually a metric of scope, but because it includes the word “day” or “hours,” it often causes confusion. How to handle this issue is explained later.

  10. 10.

    Scrum calls their first iteration Sprint 1 instead of Iteration 0. The process and goals are the same, but the terminology is different.

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 2015 Alan Cline

About this chapter

Cite this chapter

Cline, A. (2015). Project Startup. In: Agile Development in the Real World. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-1679-8_3

Download citation

Publish with us

Policies and ethics