Working with software architects - advice to project managers

486
-1

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
486
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Discuss different approaches (more later)
  • Working with software architects - advice to project managers

    1. 1. Working with Software Architects Advice to Project Managers Yaniv Pessach, PMP, CSM www.YanivPessach.com
    2. 2. 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.
    3. 3. 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
    4. 4. 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
    5. 5. 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
    6. 6. 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
    7. 7. Emerging Architecture • AKA Emergent Design • Build, Identify commonalities, Refactor • Minimal design • Associated with Agile • Caveat - If refactoring skipped, quality degrades quickly
    8. 8. Good Enough Architecture • And other ‘compromise’ architecture styles • Most common in real-world companies – Regardless of what architects claim
    9. 9. 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)
    10. 10. Also Done By Architects • Technical Oversight • Second Opinion • Technical Tie-breaking • Standardization • Long Term Technical Vision • Enforce tech-focus => reduce politics
    11. 11. Aspects of Software Architecture • Deliverables • Patterns • Styles • Not yet a settled field – multiple viewpoints, art not science
    12. 12. Judging Architecture • business drivers • high level architecture • Possible architectural approaches • Architectural attributes • Prioritize • Stakeholder input
    13. 13. Timelines - Initiating • Requirement Analysis • Project Cost/Estimate • Charter
    14. 14. Timelines - Planning • Scope • Team Selection • Identifying Activities • Schedule • Budget • Risk
    15. 15. Timelines - Execution • Architectural Artifacts • Technical Oversight • Team Education • Enable Technical Collaboration • Arbitrate Technical Ties
    16. 16. Timelines - Monitoring • “Second Opinion” on project health • Advise on error/course correction
    17. 17. Timelines - Closing • Evaluate State • Unique to the software world? Statement of Technical Debt
    18. 18. Volatile Effort Estimates • We architect best when we finish a project • Spectrum between undisciplined code and perfectionism
    19. 19. Working with Senior ICs • Competing Priorities, limited time • Assigning tasks approach may not work • Appeal to interest, benefits
    20. 20. Architects as PMs • Coordinate • Centralize • Assign
    21. 21. 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
    22. 22. Contact • Let me know if you have any more questions • My website on www.yanivpessach.com • Email via pmi@yanivpessach.com

    ×