[darya]

Hi Dan and Russ,

First of all, thanks a lot for this great book. I'm at chapter TDD right now and so far able to map your User Stories, Tasks etc. definitions to other Software Development processes like Feature Driven Development (FDD). Your decision to not stick to one Sofware Development (SD) / Project Management (PM) combination like Scrum / XP but leave room for any other combination, was right.

What I miss, is some clarification where a PM method is responsible and where a SD process is responsible for doing things. Having read HFPMP's scope management chapter, it's obvious to me that creating a Work Breakdown Structure (WBS) is definitely a SD thing. You call work a task, other like FDD call it a feature. Hence I would say that work is just an abstract name and task or feature are concrete term from SD processes.

So Work or WBS is s.th. like a Plug-in point in PMP for SD processes where a SD can integrate itself into a embedding PM method.

Maybe these topic comes later in the book, but if not I appreciate your comments on the SD/PM Plug-in issue.

Regards,
Darya

[Dan_Pilone]

Hi Darya,
First, I'm glad you're enjoying the book. A lot of thought went into whether or not to ever name a specific process. I think we made the right call by avoiding it all together; I'm glad you agree.
So this is a great question - one I'm not sure there is a simple answer for. I think it really depends on how you define your roles on a project. Let's start with the technical side of things: most teams agree that there is an architect on the project - now the argument comes in on what his/her responsibilities are. In some processes the architect's role is very outward focused. They are to defend the developers from distractions (much like a scrum master) while at the same time represent the customer's interests to the developers when there are questions regarding requirements or functionality.
There are other views of this role where the architect is very inwardly focused and is responsible for the technical baseline, code reviews, design reviews, etc. These views aren't necessarily in conflict, but it's a lot of work for an individual role.
Put on top of that your classic PM responsibilities and you have a pretty outrageous workload for an individual. So, in my experience the architect has been responsible for the technical aspects of the project and less of the PM aspects. This helps identify the division somewhat, but probably not to the level you want. In practice this has translated into:
- SD process is responsible for internal pacing of the project - iteration structure and content
- PM process is responsible for the customer facing schedule dates and overall schedule
- SD process is responsible for identifying and contributing to an overall risk and mitigation plan
- PM process is responsible for collecting, monitoring, and mitigating the project risks (which include, but aren't limited to the SD risks)
- SD process is responsible for staffing input
- PM process is responsible for outlining the staffing profile based on SD input and funding

And so on.. basically the architect and the PM split responsibilities. The architect technology focused, the PM project/PMP focused. Obviously there is overlap, and this probably isn't the clean PM method division you were looking for, but it's a start to kick this discussion off. -- Dan

[darya]

Hi Dan,

thanks for taking up this discussion. I know it's not an easy task to get PM and SD in sync. Actually I think this is one of the toughest part in software development.

But once we get it right, it should become fun to run projects in satisfaction for every stakeholder.

I agree with all you say about PMs, architects and their responsibilities they have in their domains of PM and SD. I think this discussion should result in tangible concrete mappings between PMP and SD tasks that do not overlap but add value to each other.

I know it will take some time but it's possible. What I've seen in HFPMP is that it provides a number of plug-in points where a SD process can plug-in itself.

However I need time to bring some of these I've in mind here to the discussion.

Regards,
Darya