• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Working with software architects - advice to project managers

Working with software architects - advice to project managers



Slide deck of presentation given online to 1100 project managers for PMI.org ISCoP

Slide deck of presentation given online to 1100 project managers for PMI.org ISCoP



Total Views
Views on SlideShare
Embed Views



1 Embed 1

https://twitter.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Discuss different approaches (more later)

Working with software architects - advice to project managers Working with software architects - advice to project managers Presentation Transcript

  • Working with Software Architects Advice to Project Managers Yaniv Pessach, PMP, CSM www.YanivPessach.com
  • About the Presenter • Yaniv Pessach, PMP, CSM, has served as a Program Manager, Senior Software Developer, Development Manager, Software Architect and Principal Engineer for companies such as Microsoft, Amazon, and Walgreens eCommerce. He received his graduate degree from Harvard University in Information Technology - Software Engineering. • As both a PMP and a Certified Scrummaster, he believes in merging aspects from traditional and agile practices to achieve highly functioning teams and successful projects. • He currently works as a Principal Software Design Engineer within Microsoft's Online Services Division.
  • About the Presentation • A version of this presentation originally presented to PMI.org ISCoP via the web to 1100 online project managers • The recording of the full original presentation should still be available to PMI.org members on their website
  • What is Software Architecture • Practices in the 10,000ft design of software • Define software elements, their relations and responsibilities – Team structure often follows component decomposition • Somewhere between requirement analysis and design
  • More about Software Architecture • Solve for multiple stakeholders • Tries to simplify each component • Enforces reuse and standardization • Conceptual integrity - same ‘feel’ and uses similar architectural patterns
  • Big Design Up Front • ‘Waterfall’ • Detailed specifications and SoW prior to work • Cons: Slow ramp, slow adaptively to change • Pro: Contracts, weak teams • Currently out of favor
  • Emerging Architecture • AKA Emergent Design • Build, Identify commonalities, Refactor • Minimal design • Associated with Agile • Caveat - If refactoring skipped, quality degrades quickly
  • Good Enough Architecture • And other ‘compromise’ architecture styles • Most common in real-world companies – Regardless of what architects claim
  • Time Boxed Architecture • Time boxing is an agile concept • Architecture can be reiterative • A alternative to no or too much architecture • Fits within or between sprints (if agile) • In planning and replanning (if not)
  • Also Done By Architects • Technical Oversight • Second Opinion • Technical Tie-breaking • Standardization • Long Term Technical Vision • Enforce tech-focus => reduce politics
  • Aspects of Software Architecture • Deliverables • Patterns • Styles • Not yet a settled field – multiple viewpoints, art not science
  • Judging Architecture • business drivers • high level architecture • Possible architectural approaches • Architectural attributes • Prioritize • Stakeholder input
  • Timelines - Initiating • Requirement Analysis • Project Cost/Estimate • Charter
  • Timelines - Planning • Scope • Team Selection • Identifying Activities • Schedule • Budget • Risk
  • Timelines - Execution • Architectural Artifacts • Technical Oversight • Team Education • Enable Technical Collaboration • Arbitrate Technical Ties
  • Timelines - Monitoring • “Second Opinion” on project health • Advise on error/course correction
  • Timelines - Closing • Evaluate State • Unique to the software world? Statement of Technical Debt
  • Volatile Effort Estimates • We architect best when we finish a project • Spectrum between undisciplined code and perfectionism
  • Working with Senior ICs • Competing Priorities, limited time • Assigning tasks approach may not work • Appeal to interest, benefits
  • Architects as PMs • Coordinate • Centralize • Assign
  • Key Take-aways • The architect(s) are key partners – Understand their role – Involve early – Listen carefully – Check in regularly until Closing • Assign technological decisions to architects, business decisions to business owners, and project decisions to project managers
  • Contact • Let me know if you have any more questions • My website on www.yanivpessach.com • Email via pmi@yanivpessach.com