2008-10-18

LinkedIn: Answers: How to prevent the hijacking of BPM/SOA projects by PMs who have never worked on the involved technologies (TIBCO, BEA, etc.)?

<question>
How to prevent the hijacking of BPM/SOA projects by PMs who have never worked on the involved technologies (TIBCO, BEA, etc.)?
I am currently facing and have faced this problem before where project managers (who have never particpated in, let alone manage) completely mess up BPM and SOA technology projects by giving them a direction directly opposite to that proposed by the Lead Architect (who obviously has several years experience in the BPM/SOA domain).

How should architects engage with the Project Management Office at the beginning of the project? What is the level of empowerment that should be provided to architects who usually do not have a team of developers reporting to them.

The challenge remains of making a PM execute a project that is aligned to the development methodology proposed by the architect. Any insight into this based on current or previous experiences would be appreciated.

Cheers,
Sid

</question>

I would recommend to consider socio-technical nature of BPM/SOA: *how* you do something is sometimes more important than *what* you do.

If an architect (literally "chief builder") is a person who translates a user's requirements in a built environment then "a user" is your best ally. Who is that "a user" in your BPM/SOA solution?

In my experience, a BPM/SOA solution has many stakeholders with different views, different concerns and different understanding:
• top managers
• business managers
• process owners
• super-users
• users
• business analysts
• IT managers
• software architects
• developers
• operators

ONLY the architect can explain to each of them how their concerns will be addressed and how their current working practices will be changed for better. It is important to give a correct explanation/story for each of them and use right wording, e.g. "a version of a document" means different things for a quality manager and for an IT developer.

You may have a look at my presentation below that follows this approach to explain to different stakeholders how a particular architecture brings "ability for easy evolution".

Please feel free to contact me if you need more detail.

Thanks,
AS

Links:
http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

No comments: