Project and Stakeholder

 

1. Introduction

 

Businesspeople throughout the organization have a stake in the software development process. Sometimes they are the end customer, as in the case of the delivery of a new accounting system or CRM system. Sometimes they are a proxy for the end customer, as when the sales and marketing department requests a new e-commerce website that allows people to buy the company's products more easily. In either case, these businesspeople are the “key stakeholders” or “internal customers” for the project. Both Waterfall and Agile methods require the attention of business stakeholders. But, the Agile method requires a lot more attention, consistently, sometimes over the months or years it takes to deliver the product. In Agile, the business stakeholder attends the daily Scrum meetings and gives feedback on all the micro-deliverables prepared by the programming team. That is why it is important to make all business stakeholders aware of their expected time commitments throughout the project development.

 

[Reality Check]

Were the requirements accurately transmitted to the programming team? Again, very nuanced and consistent communication must happen to achieve this goal. Here's another reality: People forget. It's unfortunate, but they do. For a little while, as the project team interacts with the business stakeholders and gathers requirements, the business stakeholders are deeply engaged. Then, the project team disappears to work on the project and the business stakeholders forget. Worse, they often start to embellish in their own heads what the software will do when it's done. The finished business requirements document is often never read. The business stakeholders look at the impressive pile of paper and just assume it contains all their hopes and dreams. It must, right? It's so thick with so many Visio diagrams. The business requirements document collects dust in a drawer. When the project is delivered, many months later, the customer declares it wasn't what they wanted.

 

2. 釐清專案/產品利害關係人 Understanding stakeholders of a project/ product

 

As we know, when we initiate a project, we think about several things. We first define the goal of the project, we identify the objectives and the trade-offs among them, and finally, we think about the organization and the stakeholders. How do we identify the organization involved in our project and the stakeholders affected by it?

 

1. Framework 1: Key questions to think about the organization and the stakeholders -  

   1. Who will be doing the work? Will it be our own in-house employees or are we relying on external contractors? And if we are relying on external contractors, when exactly do they get involved? How much is under our control, and how much are we waiting on others? 

   2. A second key question might be, who is the project manager going to be? Is he familiar with our company, is he familiar with the employees? Is he new to the setting? 

   3. We may want to consider who is paying for the project. Who is funding the project and when will those funds be available? 

   4. Next we'll think about the consumption of the project or the service. Who is going to be using the project at the end of the day? Who is our final customer? 

   5. Finally, a key question might be who else might be affected by this project? The general public, the government. How might they dictate outcomes related to our project? 

 

2. Framework 2: When we think about organization stakeholders, the second framework we can use is the stakeholders cycle - 

 

3. 1. The stakeholder cycle starts by identifying all the stakeholders that are affected by our project and that affect the success of our project. We gather information about them and we identify their agenda or interest. 

   2. We determine their strengths and their weaknesses and especially, we pay attention to how those strengths and weaknesses will affect our project and the success of our project. Then we might predict their behavior, depending on alternative strategies that we might deploy, and we identify the strategy that we would like to incorporate into our project plan.

   3. [Example (requires location adaptation)] Consider the project that has to do with developing a brand new cold press organic juice, supermarkets might be a good example of a stakeholder, and especially let's think about an example such as Whole Foods, a natural food, organic food supermarket. Well we gather information on them and we think about, what do they care about? What is their mission? What is Whole Foods' passion? In this case, following the same example, this specific chain of supermarkets thinks about healthy eating and they care about organic and making it safe for their consumers. Since we can determine, and it is clear for our project that working and cooperating with Whole Foods and with this large chain of supermarkets will be key to our success. We want to make sure we can find the strategy and that our project considers their mission. And therefore we're going to predict their behavior, based on our certifications and based on the quality of our final product. And therefore in this case our project will have to include a proper process to apply for a U.S. Department of Agriculture Organic Certificate, in order to comply with our stakeholder's mission.

 

3. Framework 3: Power Interest Grid - 

 

1. 1. This framework was developed by Ed Freeman, the University of Virginia. 

   2. Identifying where our stakeholders fall onto main axes, power and interests. Are they high power or low power? High interest or low interest? Once you've identified where our stakeholders fall, that will imply a certain strategy and a certain type of interaction. 

   3. Stakeholders that have low power and are low interest, we just want to monitor, make sure that there is no change. Similarly, stakeholders that might have high power and low interest, we would like to keep satisfied and we would like to keep them satisfied because the outcome of them not being satisfied is critical and important to think about. If those stakeholders that have high power and low interest are not satisfied and they become high interest stakeholders, that is, probably, probably a signal to us that something is not going well with our project. And therefore, if we keep them satisfied, they will remain where they are at the low interest quadrant. 

   4. [cite a personal example]

   5. Further reading: How To Get Project Stakeholders on Your Side

 

3. 使用者(以使用者為中心打造產品)Users (products are created for users to use)

 

The number one reason projects or startup products fail relates to the challenge of developing a product or service that fits the needs of the market, i.e. developing a project or product that fulfils finding this product market fit.

 

This is where user/customer-centric design (or design thinking) comes in, helping to move away from being product-centric (have you had the experience of dealing with clients who right upfront discuss product features and functionalities with you as opposed to what they want the product to achieve for the end users?) to being more customer-centric. Design thinking refers to processes, methods, and tools for creating human-centered products, services, solutions, and experiences. This approach is used in understanding and solving complex problems. 

 

Design thinking unlocks the insights and creative collaboration needed to generate innovation. In applying design thinking, you'll need to visualize a product or service that fits the needs of the market. Creating products and services for FinTech has skyrocketed over the last few years because these fit the needs of many markets. People are no longer waiting for the big banks to solve and address opportunities brought by the rapid advancement in technology. 

 

We will cover this topic in-depth in Part B and Part C but we want to draw your attention to one common comment we get from project managers. A lot of project managers think it is not their responsibility or they lack the professional skills to understand the user needs and hence they think it is better to leave people like business analysts to handle this. On the contrary, we think it is utmost important for project managers to grasp the end-users’ needs throughout the project for the following reasons:

 

1. Career advancement to be promoted as a business analyst

From our experience, all the most valuable business analysts have extensive project management experience. A project manager who has a strong sense of users and product-market fit (in other words, commercial sense) are those who are sought after not only locally but also by all the top corporates and startups around the world.

 

2. Help you understand what are high impact tasks

Do you remember this diagram?

 

We have explained that for projects to be effectively managed, a project manager needs to be able to identify what are the high value/ high impact tasks and properly prioritize tasks accordingly. One key benchmark to identify high impact features will be aligning it with the benefits that end users want from the product/ project.

 

3. Understand user needs is a continuous process

Arguably understanding user needs is a team effort and a continuous process rather than a one-off task only by a dedicated business analyst. A successful project leader will be proactively communicating the user needs with all stakeholders and making sure that the feature development will not be deviating away from what the users actually want.

 

4. 企業利害關係人 (只要產品有使用者，企業就存在商業目標)Business (when there are users, there is market value and money to make)

There may be many internal customers for a software project. But one of them is usually most important and becomes part of the project leadership. In cases where there are many internal stakeholders, this person serves as the “voice” for all of them and we usually refer to that person as the project owner or product owner. 

 

For example, the key business stakeholder might be the head of finance who knows the company needs a new accounting system. It might be the head of sales who is pushing for a new CRM system. It might be the head of logistics who wants a new method for tracking inventory. Or it might be the head of marketing who wants a new ecommerce website for selling products. In any of these cases, it's usually easy to identify the key business stakeholder. She is the person raising her hand and saying, “Hey, we need this!” 

 

Sometimes there is more than one key business stakeholder; but more often than not, there is one main key business stakeholder. It is important for project managers to identify the project owner early in the project and gain trust with this person as he or she will likely be the key decision maker who will make or break the project.

 

Business stakeholders with little experience in technology often look at the tech team with wide eyes and palms raised to the sky and say, “I don't know? What should we do?” After a few interactions like this, the programmer may think, “It's my responsibility to decide.” Don't let this happen in your organization. As with the example of the parents, often the least technically expert people in the whole firm are responsible for the firm's technological strategy. This is especially true if the business is undertaking a large software project with significant budget and strategic implications. It's the responsibility of the project leadership—the program manager, project manager, and (often) business analyst—to make sure the business stakeholders have all the information they need to make strategic decisions. But the business stakeholders must step up to their responsibilities.

 

It is critical for business stakeholders and organizational leadership to accept that however unprepared they may feel, they are the strategic decision makers in this project. One of the things most fatal to the software development process is when the business leadership abdicated its responsibility due to a lack of confidence. Projects dissolve into debate and chaos. But with support and determination, non-technologists can make good technology decisions without formal training. It's one of the main reasons why you are attending this class. Businesspeople can do it by asking the right questions and getting the right support.

 

[cite some actual examples dealing with business project owner]

 

5. 專案管理(讓產品誕生的所有事情都包含在此) Project management (everything that involved that make this product happen)

 

1. The role of a project manager

Software product manager is a central management role. Let us recap what we have covered so far. Project manager is in charge of the success of a software product. But the role is much more than just managing a project but also to empathize what the product does and its unique benefits, like a real user. Successful project managers will have the following traits:

1. Great software product managers have mastered multiple disciplines. 

2. They can speak to both clients and developers in their terms. They can listen and imagine a client's vision, communicate effectively with their development team members, and motivate the team to achieve the best outcomes. 

3. They can also manage clients' expectations, and they also know how to get the best efforts out of their development team. 

4. Success of your product also depends on solid teamwork. Programmers, testers, interface designers, graphic artists, must work together. Your role is to empower them to bring their best efforts to your project. 

 

Software product management is a leadership role. Capable managers earn the respect of both clients and team members. Great managers are sought after for their track record of successful product deliveries. Whether you want to make a move from developer to product manager, or you understand the business side and you want to move to more of a hands-on role in shaping the software, or maybe you want to look for a career change and work more in software project management.

 

[Interview soundbites from PMs to show how they step up to the leadership role. I suggest we provide these examples for our interviewees to read to inspire them to come up ones of their own]

(Example 1)

My role actually is one of leading software development teams. I do see myself, though,

as a product leader, and I encourage everybody on the team to see themselves as a product leader. I have a software product manager on my team. 

 

We work closely together in partnership. The product manager works to bring requirements to me, and to help me understand what our customers need, and then I work to fulfill those requirements with the team.

 

So a lot of what I do is to define a vision product strategy, product road map, and also specifications for the development team, as well as our experienced design team.

 

(Example 2)

What excites me, what challenges me, is getting the engineers, the testing team, the documentation team, understanding in no uncertain terms what the problem is we are trying to solve, that makes my day.

 

The product manager meets with the customer, they get an idea, they get a vision for how something could be, they articulate that vision back to their engineering team and the associated stakeholders, and then they actually see it be produced as working software. And it's tremendously satisfying for the product manager to see it actually delivered and to then see the impact that has on the customer and their reality.

 

Seeing how customers react to the finished product, reading reviews about it, seeing it in stores, is enormously rewarding. 

 

(Example 3)

Getting the team to rally around the problem. If people show up for work because there's a job for them, they don't innovate. They'll do what you tell them to do and they'll go home. If they internalize the mission of the problem you're trying to solve, magic happens.

 

Ambiguity is huge. I think we see that customers don't always have the ability to explain what exactly it is that they want. And so we tend to employ a lot of different strategies to uncover what it is they want, even if they can't tell us. So we might watch a customer. We might sit and watch them do their job for a while to help get past the ambiguity of them saying something, even and to find out what they actually need. People can have 100 different ways of solving it, right? And so this is where, for me, the approach of experimentation, rapid iteration, is really the key to solving that. So it’s acknowledging the differences of opinion and the lack of shared vision, and say okay. What are we gonna do to actually solve that and how do we determine whether that's

the right course of action or not?

 

(Example 4)

As a leader, first and foremost, you need to be able to do three things. You need to be able to motive with your vision, you need to be able to organise the work that needs to be done, and you need to be able to innovate. Frankly, if you can't innovate yourself, it is your job to hire people who can help you innovate.

 

They need to be able to hear what somebody is saying, what a customer is saying, and turn that into a requirement and ultimately a specification that an engineering team can build and deliver.

 

Next thing, you need to be able to communicate. As a person who communicates, or sells, your vision across the organization at all levels, to executives, to engineering teams, to sales teams, to marketing teams. You need to be able to understand at what altitude all these things exist at and what messaging resonates with them.

 

The ability to form really great relationships, think strategically. Also be really tactical when need be. It's not about you. It's never about you as a product leader. It's about the customer problem. Your job, my job, fall in love with a customer problem. 

 

(Example 5)

People will either start from the business side and realize they've got some interest and skill at software, and they understand kind of the general idea of how software is built. And so then they'll get a little more technical aptitude and they start to get involved in things from that side.

 

Personally, I came from a comp sci background. I grew up as a programmer. And slowly I've migrated into a product leadership role. But I've also seen people with music majors who have become amazing product leaders. What do we have in common? Me, who has a computer science degree and the guy who has a music degree, is, first and foremost, leadership. If you're able to motivate people, able to organize people and can innovate, you can do well in product management. I think other's come at it from the engineering side, where they're a great engineer, but maybe they decide they've got more passion for that vision, and the planning side of things, and the collaboration, rather than the implementation side. I think a lot of product managers learn on the job, when you get right down to it. 

 

(Example 6)

Understand this, you are here to lead people, you are here to lead a process, you are here to solve a customer problem. If you believe that that is you, from a self-awareness perspective, apply for a PM job.

 

They should get to know their engineers, they should get to be very well aligned with the problems faced by engineers, with the opportunities that engineers can bring to the table, and really focus on that partnership, I think. Customers and customer research is critical, and that's a basic skill of a product manager, so that's just expected. I think over and above that, though, to just really be good at building those partnerships with their own team and, again, with their

stakeholder teams as well.

 

For me, it's be customer obsessed. Be grounded in the customer, understand them really, really well, because it's gonna be your job to represent them. If you start with that, and you can do that really well, if you can understand your customers at a deep level, then you're already kind of ahead of the game, if you will.

 

2. Teams and Team Roles and Responsibilities Defined

Getting the right team in place is, without question, the most important thing you can do to ensure the success of a software development project. But wait! You may ask, “How do I build a team when I don't even know the technology I'm choosing? Don't my team members have to be familiar with the technology? The answer to all these questions is “not necessarily.” First, let's discuss teams.

1. 1. Teams and the Roles on Teams

Over the years, I have noticed that businesses tend to be unfamiliar with the roles necessary on a software project. There are lots of blurred lines, mixed up roles, missing roles, double teaming roles, and so forth. 

 

Without a clear understanding of roles, it's impossible to staff a project. Whom are we looking for, and what holes do we need to plug?  A common comment when people learn all the roles is, “Wow! There are a lot of them!” Yes, there are. Keep in mind a note from the Introduction. I am speaking here about medium- to large-sized software projects. On smaller projects, it's common for one team member to wear multiple hats. How and whether to blend is directly related to the size of the project and to the talents of your team members. In a small project, it is of course appropriate for team members to do several jobs. The larger the project, however, the more distinct the roles need to be. 

 

Still, the structure is the structure. Anyone tackling a software project must be aware of the basic roles, just as anyone entering a soccer game must know about the standard game positions. Once you understand that, you can make decisions on your own. 

 

All projects have the following: 

 

• A project leadership team 

• A project execution team 

• Business stakeholders, also called “internal customers”

 

1. 2. Project Leadership

The project leadership can be understood as a bridge between the “techies” and the business. As a bridge, the project leadership team will have technology folks and businesspeople. A typical project team will look something like this (we should draw our own one with something like this):

 

(Source: Murray, Anna P.. The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond (Wiley CIO) (p. 30). Wiley. Kindle Edition. 

 

1. 3. 1. The Key Business Stakeholder

The key business stakeholders have been discussed in the previous section.

 

1. 3. 2. The Project Sponsor

This is the business manager charged with overseeing the software development project and with the accountability for its success or failure. This is the person in the business with responsibility for the project. Top leadership has come to this person and handed them the directive to make sure this project gets done. This person is often the chief information officer, chief digital officer, or even the chief operations officer. A need has been identified, a project must be started, and the project sponsor is on the hook for getting it done. All the teams report to this person who, in turn, interfaces with the rest of the organization. 

 

The project sponsor's role is as key project decision maker—she is, as the saying goes, where the buck stops. Another role is as a buffer. It's largely the project sponsor's job to provide the bridge between the project and the rest of the organization, and to act as a buffer between the organization and the technologists. Without this buffer, the technologists are going to be faced with too many clamoring voices from the business side, all stating their various (and sometimes conflicting) needs, wants, and desires. 

 

In essence, the project sponsor becomes the negotiator-in-chief. For example, when the technology team says a business requirement is too complex and time consuming, but the business stakeholders say it is a mission-critical piece of functionality, the project sponsor will need to mediate the solution. 

 

Hint #1: The project sponsor and key business stakeholder are sometimes the same person. Say, for example, the CIO says the company should transition all servers to the Cloud so that he can better scale resources across the business. In this case the CIO is both the main internal customer and likely to be the project sponsor. 

 

Hint #2: The project sponsor has a very close interlock with the program manager, and they often split responsibilities.

 

1. 3. 3. The Program Manager (Business Development Manager/ Account Manager)

People familiar with advertising agencies may be more comfortable with the term “account manager.” The program manager role is usually seen on medium to large projects. This is a person experienced in running large software projects who organizes all the teams, calls the meetings, gives directions, identifies needs, and leads all the other team members through the processes of deciding on technology, picking team members and vendors, gathering business requirements, breaking down the project into tracks, budgeting, and leading execution. If the project sponsor is nontechnical or inexperienced in the type of technology under consideration, the program manager will serve as her trusted technology partner and guide through the process. 

 

If you are getting the sense that this person is a kind of general in charge of forming and executing a battle plan, you're right! She is! She would be the one to lead the business such as choosing waterfall or agile as the project approach.

 

On the client side, the program manager is often an outsourced role, but sometimes an internal resource fills this role. The project sponsor is often a businessperson (e.g., chief operating officer), and the program manager is often a senior technologist with years of experience rolling out software projects and is comfortable with two or more project managers working under her.

 

1. 3. 4. Project Manager

If you find yourself getting confused between program manager and project manager, think of the program manager as the ship's captain and the project manager as first mate. Figure 4.2 may help in clarifying roles.

 

(Source: Murray, Anna P.. The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond (Wiley CIO) (p. 33). Wiley. Kindle Edition. )

 

The project manager (PM) is a level down from the program manager. He or she is formally trained in the methods of project management. He is in charge of interacting daily with the technical team, making and tracking the detailed plans, and using project management tools to report on progress. You will see this person conducting daily status meetings, preparing agendas, capturing to-dos and follow-ups, and making sure they get done. This person will have mastery over project management tools such as specialized spreadsheets with lots of macros, ticketing tools, and project planning tools such as Microsoft Project or Jira Portfolio. 

 

A good PM is worth his or her weight in gold, and no software development project can move forward without one. The PM will know how many hours have been assigned to program a certain widget, and if the task is on schedule.

 

1. 3. 5. Multiple Project Managers

If a software development project involves one or more vendors, there needs to be a PM at each of the vendors. For example, on a software development project with three vendors, ideally there would be four PMs. The business itself must have one, outsourced or on-staff, and there should be one at each vendor. When you start off with a vendor, make sure to ask them who the PM will be. This is a role that often gets left out, but is critically important. If you have a lead or major player vendor on the project, their PM may, in certain circumstances, serve as your PM. 

 

One big mistake people often make in the selection of a software development project manager is in thinking they need a PM who understands their particular industry. For example, in media companies, the trend is often toward selecting PMs who understand the terminology such as “headlines,” “bylines,” “slugs,” and so forth. If a PM isn't facile with the vocabulary, confidence is immediately lost. 

 

And yet, nothing could be farther from the ideal strategy for selecting a PM. If you are engaging in a software development project, you want a PM who excels in project management for software. This is an invariable rule.

 

1. 3. Project Team

After the project leadership, we have the actual project team. These are the people with the “hands on the keyboards,” so to speak: gathering requirements, analyzing business needs, defining tasks, and doing tasks.

1. 4. 1. The Business Analyst

The business analyst (BA) is the person who collects, digests, and codifies all the software development requirements from the business stakeholders. This person will often be found interviewing members of different departments, learning from them how the software will meet their needs and what it is expected to do when it's done. The BA then writes all this up in a way that both the programming team and businesspeople can understand, with all the necessary level of detail, including all the diagrams and descriptions programmers will require. 

 

Oftentimes people think the BA and the PM are the same person or try to blend these roles. But in general, the roles of BA and PM are very distinct. For one thing, the PM has enough to do. For another, the BA is often more of a “big picture thinker” whereas the PM must be quite detail oriented.

1. 4. 2. User Experience

The user experience (UX) person is a professional who designs the user interaction (i.e., which clicks lead to what) and navigation in a piece of software. This person will often be found developing sitemaps and wireframes (mockups that focus on functionality). Many times a UX person develops interactive wireframes that provide some level of click response, so you can see how the software will behave. Sometimes the UX person can often also do visual design. Sometimes the reverse happens—a visual design person also does the UX.

1. 4. 3. User Interface Designer

Different from graphic designer or multimedia designer, for software development projects, it's especially important for the designer to be integrated into the team and to consider blended roles such as user experience and design. It is much better to avoid designers who come from a primarily (or exclusively) analog world, meaning those who have done most of their design for print. Ideally, your designer should have a fundamental understanding of the technologies being used and what is possible within that technology.

1. 4. 4. The Programmers

Broadly speaking, any large piece of software can be described as having a front end and a back end: The front end is the “interface,” or the part of the software that users see and experience while the back end is the “processor” that uses the information collected by the front end. Consequently, your programming staff will probably break down into two levels of engineers: front-end and back-end programmers. 

 

It's important to understand that front-end programmers are not user experience people or designers. What they do is take the user experience and design material and write the code that translates it into the actual front-end screens. They're often working with technologies called CSS, Javascript, and HTML. 

 

Back-end programmers, on the other hand, are often database programmers. They are in charge of putting in place the systems that will feed data into the front end and take data from the front end into the back end where it's processed and stored.

1. 4. 5. System Architect

A common problem in software development projects occurs at the end, when the software is deployed on the actual machines where it runs. Maybe there are integrations and different systems that need to talk to each other. Maybe the site has to support tons of traffic and lots of simultaneous users. 

 

Conflicts arise when something isn't working. Often, programmers blame the hardware people for not having enough machines or the right machines, while the hardware people blame the software people for writing code that doesn't run well on the machines they have. 

 

To avoid the conflict I just described, it's important to have a person— often called an architect—as the go-between for the programmers and the managers of the hardware. This person will be accountable for developing what's called an “architectural map” or “footprint.” This architectural map will identify the number of machines, types of machines, and size of machines necessary to run the software. The architect will work with the systems administrator to set things up so that integrations can happen.

1. 4. 6. System Administrator

Obviously the software will need to be deployed on machines that will run it. There must be a person in charge of this hosting environment. That's called the systems administrator or Sys Admin.

1. 4. 7. DevOps, etc.

(I think we need to update a paragraph about roles like DevOps)

 

 

(Source: Murray, Anna P.. The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond (Wiley CIO) (p. 36). Wiley. Kindle Edition.)

 

1. 4. Team Member Choice and Blending Roles

Previously, I've outlined the key roles found in software development projects. With that list you will have a starting point to get all the bases covered. As you plan out your team, ask questions like: 

 

• Who is going to keep track of tasks, schedules, and budgets? (the PM role) 

• Who is going to collect business requirements and document them? (the BA role) 

• Who will give us the wireframes showing us how the software will behave and interact? (the UX role)

 

1. 1. 1. Getting All the Roles Covered

Looking at this list of roles, the number of people involved can be enough to make you think your budget is blown before you start. And it's true: In very large software projects there may be quite a large team, with several people playing each role. But in smaller projects, these roles are frequently blended. 

 

However, many people inappropriately blend roles without even knowing they're doing it. This often leads to trouble. Assuming a particular task is part of a person's job when it's not leads to conflicts with staff and vendors. 

 

For example, a member of a programming team may find, midway through the project, that his boss expected him to be on top of the interactive user experience, but that wasn't his expectation at all. A businessperson may think, “Well, this programmer is working on the front end, right? That means doing all the interactions that a user will experience.” Again, this is a common, sometimes fatal, misunderstanding of roles. 

 

A similar misunderstanding happens with design and user experience. A visual designer may have little or no background in user interactions; yet in many software development projects, user experience is commonly handed over to designers, with negative results. 

 

Then there are the missing roles. I've seen vendors make certain requests of the project manager only to discover there is no project manager, because the client expected them to provide that service. 

 

All these examples spring from a lack of understanding of the roles necessary to execute a software development project. And they can lead to budget and schedule overruns, as well as conflicts and discomfort.

 

My point is that even if you blend roles, you'll need to remember that all of the key roles must exist at some level. The critical skillsets must get covered so there are no gaps. All the jobs must be done. Only once you are clear on what's needed, then you start to mix and match. 

 

As mentioned earlier, the sole unbreakable rule when it comes to blending roles is not to blend the PM (project manager) role with anything else. I have found this to be true not only because of the number of things that the PM has to do, but also because of skillset and personality reasons. The PM stands alone. 

 

1. 1. 2. Real-World Examples for Role-Blending

What follows are some real-world examples where role-blending works well.

 

• Project Sponsor as Program Manager

If the project sponsor has worked on a software project before. Further, she has cleared a good chunk of her time to lead kickoff meetings, be present at weekly status meetings, help the business analyst shake down the business stakeholders for requirements, and respond to red flags raised by the PM. 

 

In this case, the project sponsor may also serve as the program manager.

 

• Program Manager as Business Analyst

Another common example is for the program manager to serve as the business analyst. Often, the program manager has come up through the business analysis track. She certainly has to do a lot of analysis in her job! In this case, she may be the one to write the business documentation and take over the BA role.

 

• Front-End Programmer as User Experience 

Some front-end programmers with good communication skills and experience in user interaction can sometimes do user experience.

 

• Design, UX, and Business Analysis 

These three roles (design, user experience, and business analysis) can sometimes be found in one person. It can be appropriate to blend these roles, especially on small projects. Indeed, I myself have performed all of these tasks on certain software projects because I have a background in business analysis, user experience, and design—and I'm also a senior technologist. In terms of cost-efficiency, this is obviously an ideal situation.

 

• Back-End Programmer as Architect 

A good programmer (especially a good back-end programmer) can often play the architect role. But be careful here: Not all programmers understand the hardware side. In fact, it's becoming less common these days, as technology trends distance programmers farther and farther away from the hardware.

 

It's been my experience that programmers who are more seasoned (often, this literally means older) have greater experience on the hardware side and can interact more effectively with a hosting company.

 

• SysAdmin as Architect 

Similarly, a very experienced systems administrator can serve as an architect and lay out a systems footprint; this is especially true for small- and medium-sized projects. For larger projects, it is helpful to have a very senior technologist serving as the architect. That person will have a thorough understanding of the interplay between hardware and software as well as networking and integration issues.