I work on a lot of really large software projects.  Over the years, it has become clear to me that three roles, and the interactions between people in those roles, are really vital for the success of a software project. These three roles are the Project Manager, Business Analyst, and Project Architect. This article discusses these three roles and their interactions.

The Project Manager is responsible for interactions with the Project Sponsor, and for managing the people, budget, and schedules of the project. The Business Analyst is responsible for determining the goals and business requirements of the project, communicating that information to the project team and project stakeholders, and verifying that the goals and business requirements are met. The Project Architect is responsible for determining the technical requirements of the project, interacting with Enterprise Groups to determine Enterprise level technical requirements for the project, and for guiding the technical team in the implementation. Decisions made by one of these people will impact the work of the others, so all three people work closely together throughout the project to accomplish the goals of the project.

In a very small project, the three roles may be filled by one person. In very large projects, each role may be a lead over a team of people who fill the role.  There could be a Project Manager managing a group of  assistant Project Managers, a Lead Business Analyst managing a team of Business Analysts, and a Project Architect managing a team of Software Architects and Designers.  This is not theory – I have often worked on projects large enough to require teams of people to fill these roles.

In this approach of sharing the project leadership between three roles, the Project Manager is ultimately responsible for the success of the project. The Business Analyst and the Project Architect report to the Project Manager, but being senior members of the team, they will often interact with the Project Manager as peers, each bringing a particular viewpoint and set of concerns to their meetings about the project.

The Project Manager, Business Analyst, and Project Architect meet regularly (at least weekly) to talk about the project and any issues that need to be addressed. Some issues will be resolved by one role, while others may require the collaboration of all three roles to resolve. It is important to the project that the three people in these roles respect each other’s expertise and talents. A smooth working relationship between the three roles leads to a smoothly running project.

Some projects may require additional leadership roles, such as a Deployment Manager or Test Manager.  So the leadership team may be larger for those projects.  I focus on the roles of Project Manager, Business Analyst, and Project Architect because every project I have seen needs leadership in those areas. The larger the project, the more work there is to do, and the more need there is to divide these roles among multiple people all of whom have leadership responsibilities.

===============================================

Now it is your turn.

Think about projects you have worked on.  How did the relationships between the Project Manager, Business Analyst, and Project Architect affect your project?  What other leadership roles have you seen on a project team?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

I was recently helping a friend staff a fairly large project with a team of very experienced, very skilled people. I mentioned that people were really excited about the opportunity. He asked me “Why are they excited? What is it about this project that makes people want to work on it?”

That led us to a discussion about teams of highly skilled people and what motivates them to want to work on a project.

I believe several factors come into account. Very skilled people like to work on projects with:

• Other very skilled people
• Confidence in the success of the project
• An atmosphere of mutual respect
• A long enough duration to build relationships

Very skilled people like to work with other very skilled people. You might think, “It must be aweful having all those big egos together.” In fact, I have found the opposite. I have found that when someone is truly very good at what they do, they are very easy to work with. It is the people who are not really all that skilled, who are afraid someone will find out they are not all that skilled, who exhibit the “ego problems” on a project.

This does not mean everyone on the team has to be very skilled, but it does mean that several people should be at the same high skill level. Very skilled people love sharing ideas with other very skilled people. They are typically patient with someone who is really trying to learn. Very skilled people have very little patience with people who claim to be experts, but who are really not that good, and who refuse to listen to anyone else.

Another thing that attracts very skilled people is confidence in the management team. Everyone likes to be on a successful project. Very skilled people are no different. If they believe that the management team has the skills to be successful, and that the project has support from upper management, then they will be very interested in the project.

Long project duration can be appealing, especially for contractors. It is very interesting to work on the whole project rather than just a few weeks at the beginning. You get to find out “how the story ends”. Also, a long project gives an opportunity to build relationships, especially with the other very skilled people on the team.

An atmosphere of mutual respect is critical. When the project team all respect each other and the stakeholders, magic can happen. A cohesive team will outperform other teams every time. An atmophere of mutual respect is vital to creating a cohesive team.

Will there be disagreements? Of course! And those disagreements will sometimes be loud, simply because you have a number of people with very strong opinions. But if everyone has respect for each other, those disagreements will be worked out without animosity and to everyone’s satisfaction.

Where have I seen these kinds of teams in practice?In musical theater with actors, on software projects with developers and with business analysts, in startup companies of various kinds, and on various kinds of team projects at universities. The basic appeal is common in all these situations. Very skilled people like to work on projects with:

• Other very skilled people
• Confidence in the success of the project
• An atmosphere of mutual respect
• A long enough duration to build relationships

===============================================

Now it is your turn.

Have you worked on a team with very skilled people? Have you had to put together a team of very skilled people? What do you think motivates them to join your team?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.

In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.

In this environment, it is really good to have a team of Business Analysts who work collaboratively on all the requirements of all the projects. Another approach is to have one or more Business Analysts work on the shared requirements, then have Analysts on each project work on the detailed requirements for that project.

If you do not have that kind of relationship between Business Analysts in your company, it is good for everyone to work informally with the Analysts on the other projects to share work as much as possible. This will lead to greater consistency and will avoid wasted effort in developing the same requirements multiple times.

You can use tools such as DOORS or Rational Requisite Pro to show the relationships between the requirements in different projects. For example, you might define a ReqPro project for a set of common requirements that all the projects share, then put a folder in that ReqPro project to store the requirements of one software project. That way, all of the related projects can see what is common and what is specific to a particular project. By reviewing the requirements of other related projects, a project team may find some similarities they can take advantage of.

If you have to keep one version of a set of requirements for one set of projects, and develop a new version of those requirements for another set of projects, then you would likely want to copy the first set of requirements, for example into a new ReqPro project, then edit the requirements in the new project. You can set up a trace relationship between the relationships in the two ReqPro projects.

I do not know DOORS, but assume you can set up similar structures in that tool.

A good book for project teams involved with complex projects is “Designing Software Product Lines with UML”, by Hassan Gomaa.

I have also written a paper with an example of a system of systems/product line approach to requirements. It is called “Requirements Structure in a System of Systems / Product Line Architecture. You can find it at:

http://www.writingusecases.com/wordpress/index.php/
report-requirements-structure-in-a-system-of-systems-product-line-architecture/

===============================================

Now it is your turn.

Are you working on a set of complex, inter-related projects? Are some of the techniques suggested here or in the paper useful to you?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE