Your SlideShare is downloading. ×
Working with software architects - advice to project managers
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Working with software architects - advice to project managers

373
views

Published on

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

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Discuss different approaches (more later)
  • Transcript

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

    ×