The Brandeis GPS blog

Insights on online learning, tips for finding balance, and news and updates from Brandeis GPS

Tag: agile project management

Making the case for agile project management

Many of today’s organizations seek to build productive work environments where teamwork is encouraged and tasks are completed in a timely yet flexible manner. As the traditional office setting becomes increasingly obsolete, new technologies have allowed colleagues to work together from different time zones and different locations across the world. While companies and clients don’t always have the opportunity to have face-to-face interaction during the development process, Agile Project Management allows for constant communication and integration of changes in a collaborative manner. The goal is to ensure that all stakeholders remain satisfied as they work together toward project completion with input from all parties, and without delaying the development process. Agile Project Management empowers project stakeholders to collaborate and execute a plan while quickly responding to changes in the industry.

To help project managers adapt to and embrace this dynamic approach, Brandeis GPS offers an online Agile Project Management course that covers characteristics and delivery frameworks. The course also explores how agile methods differ from traditional project management, along with how to recognize projects that may be suitable for agile techniques. Topics covered include Scrum values, roles and deliverables; additional agile and iterative methods; scalability and enterprise-wide considerations.

Those interested in the course who do not yet wish to pursue a full master’s degree can still participate. At Brandeis GPS, you can take up to two online courses without officially enrolling in a program. This is a great opportunity to get to know our programs and approach to online learning. View our full course catalog here, and preview our spring 2017 courses here.

Questions? Contact our enrollment team at gps@brandeis.edu or 781-736-8787.

Brandeis University’s Graduate Professional Studies division (GPS) is dedicated to developing innovative programs for working professionals. GPS offers 11 fully online, part-time master’s degrees and one online graduate certificate. With three 10-week terms each year, Brandeis GPS provides exceptional programs with a convenient and flexible online approach. Courses are small by design and led by industry experts who deliver individualized support and professional insights. For more information on our programs visit the Brandeis GPS website.

The Art and Science of KPIs

By Phil Holberton

Every business leader needs to organize a set of KPIs. These KPIs have two purposes:

  1. To track the progress of a business.
  2. To motivate the organization to stretch and achieve its maximum performance.
KPI Capture

Click to view Phil’s March 2016 webinar on linking performance management to KPIs.

Where Do You Start?
Begin with a few KPIs — five is a good number. Choose KPIs that drive financial results; those KPIs that can measure the performance of the team or company. KPIs need to measure critical activities and the effectiveness of those activities, such as customer retention rate or average order size. Choose those KPIs that you can frequently measure, whether it’s weekly, daily or monthly. Assign responsibility for those KPIs — someone on your team needs to take ownership.

The Technical Aspects
Select KPIs that you can calculate easily. On the surface, everyone should be able to understand them. The top KPIs are those that indicate if individuals are doing their job, and can motivate them to change their behavior and influence the results. Spending is an easy KPI to use — am I under/over budget? Another is sales — can I do something to create improvement in the sales results? Can I make one more sales call or go that extra mile for a customer that results in incremental business?

The Emotional Impact
Psychologically, employees will look at KPIs as their individual report card – how did I do? The trick for the leadership team is to develop and use KPIs to help motivate its employees, not use them as a demotivator. If KPIs are used to discipline an individual, they will fail and not be supported by the rank and file. Use KPIs as a way to measure your progress and as a coaching tool to attain even more effectiveness from the organization.

Identifying the right KPIs is not easy – yet it can be very simple to organize a few KPIs that everyone can wrap their mind around and support. Why is it not easy? Because we have many choices. If you ask ten employees, you may get ten different lists of KPIs. If we step back, I can safely say there could be hundreds of KPIs, each of them having a precise significance yet can be distracting if used only by itself. In this case, the saying “Less is More” prevails.

KPIs, when well established, can be a system that allows for continuous improvement, allowing you to refine your business processes over time, become more efficient and continue to drive overall financial and employee performance. Use KPIs as a means to view the glass as half full, not as half empty and bringing the best out of your employees. Everyone will feel better about themselves.

Ask yourself, am I a leader?

Phil Holberton is the founder of Holberton Group Inc. – Speaking of Leadership, a business advisory firm specializing in strategic, organizational and executive coaching. He also teaches courses in the Project and Program Management and Strategic Analytics programs at Brandeis University Graduate Professional Studies.

My Student Experience

Danita Sutton is a recent graduate of Brandeis GPS’ Master of Science in Information Technology Management  Program. She is also a Senior Business Operations Analyst at EMC. Below is her account of her educational journey at Brandeis GPS.

IMG_1293“I was very nervous taking an online course let alone pursuing my Master degree in a 100% virtual environment. The first day I opened Latte I was full of anxiety and overwhelmed because this was so new to me.  This feeling of anxiety was quickly removed as I read through the professors instructions and read the responses from my fellow classmates, I was not in this alone and I had a community of people who were willing to help me out.  This community of fellow classmates set the tone for the amazing experience I would have as I moved through the GPS program.

The strength in this program is the experience of the Professors, I was impressed with their knowledge in the course they were teaching and they were willing to share that knowledge with us to help us improve and build on the course material and apply it to our personal and professional life experiences.

The material was relevant and dealt with current issues we face with virtual teams, how to communicate and negotiate with them, how to manage projects and the software that we are using now, and organizational and operational strategies. program-hero-itm1

Finally, I don’t know what I would have done without my student advisor, Janice Steinberg, who kept in touch with me, answered me promptly every time I had a question (and I had a lot of questions), and was a great support system.  The Brandeis GPS program has forever changed my life and I am very grateful that I was able to be a part of such an incredible and wonderful program and community of people.”

 Click here to subscribe to our blog!

Footerindesign

Are You Running from Problems or Solving Them?

By: Johanna Rothman

Originally from: http://www.jrothman.com/blog/mpd/2014/05/are-you-running-from-problems-or-solving-them.html

Back when I was a manager inside organizations, I had many days that looked like this:

  • Meetings at 9am, 10am, 11am.
  • Working meeting through lunch (noon-1pm)
  • Meetings at 1pm, 2pm, 3pm.

I finally got a chance to check my email at 4pm. That’s when I discovered the world had blown up earlier in the day! (This is before cell phones. Yes, there was a time before cell phones.)

resource-schedulingI then ran around like a chicken with my head cut off until I left work at 5:30pm, because, yes, I had a family, and, yes, I had to leave at 5:30pm. I either made dinner or picked up children, depending on my agreement with Mark.

We did the family stuff until 8pm, and when the kids went to sleep, I went back to work.

No wonder I was exhausted. My decision-making sometimes suffered, too. No surprise there.

Luckily, I had some days that did not look like this. I could solve the problems I encountered. And, some of these meetings were problem-solving meetings.

However, I had jobs where my senior managers did not manage their project portfolios, and we had many crises du jour. My VP would try to catch me on the way to my next meeting, and attempt to get me to “commit” to when a patch would be available or when we would start, or finish a project.

I swear, one of my VP’s used to know when I went to the ladies’ room. He did yell at me through the door, just as in this management myth.

I finally put my foot down, and said I was no longer going to meetings that weren’t problem solving meetings. Have you read the chapter about meetings in Manage It! Your Guide to Modern, Pragmatic Project Management? I wrote it for project managers and for ProjectManagement_03managers who run around like the proverbial chickens. I wrote Manage Your Project Portfolio for managers like me who had well-meaning senior managers who had trouble making decisions about which projects to do.

This management myth is something I see often in organizations. This one is the one where people are running around so often they don’t actually solve problems.

Many problems are a combination of several problems. You might have to separate the problems and attack them in sequence. But, you might have to see the whole first, because there might be delays. The overarching problem is this: if you don’t give yourself enough time as a problem solving team, you can’t tell what the problem is. If you can’t tell what the problem is, you can’t solve it.

Problem solving tends to go through the process of:

  • Problem definition: What do we think the problem is?
  • Problem discussion: Let’s get all the divergent ideas on the table. Brainstorm, whatever we need to do.
  • Select a solution: Converge on a solution, trying out the ideas, understanding the results of each potential solution
  • Determine an action plan, with dates and people’s names associated with each step

Your problem solving might vary from this a bit, but that’s the general idea.

If you never give yourself enough time to solve problems because you’re always running around, how can you solve problems? It’s a problem. (Like the recursion there?)

That’s this month’s management myth, I Can Concentrate on the Run. Maybe your myth is that you can concentrate in a 10-minute standup. Maybe your myth is that you can concentrate on your drive into work. You might be able to, for some problems. Complex management problems require more than one person to solve them. They require more than a few minutes thought.

How do you solve complex problems in your organization? Do the problems run around the organization for a while? Or, do you solve them?

Johanna Rothman

Is an Average of Averages Accurate? (Hint: NO!)

by: Katherine S Rowell author of “The Best Boring Book Ever of Select Healthcare Classification Systems and Databases” available now!

Originally posted: http://ksrowell.com/blog-visualizing-data/2014/05/09/is-an-average-of-averages-accurate-hint-no/

Today a client asked me to add an “average of averages” figure to some of his performance reports. I freely admit that a nervous and audible groan escaped my lips as I felt myself at risk of tumbling helplessly into the fifth dimension of “Simpson’s Paradox”– that is, the somewhat confusing statement that averaging the averages of different populations produces the average of the combined population. (I encourage you to hang in and keep reading, because ignoring this concept is an all too common and serious hazard of reporting data, and you absolutely need to understand and steer clear of it!)

hand drawing blue arrowImagine that we’re analyzing data for several different physicians in a group. We establish a relation or correlation for each doctor to some outcome of interest (patient mortality, morbidity, client satisfaction). Simpson’s Paradox states that when we combine all of the doctors and their results, and look at the data in aggregate form, we may discover that the relation established by our previous research has reversed itself. Sometimes this results from some lurking variable(s) that we haven’t considered. Sometimes, it may be due simply to the numerical values of the data.

First, the “lurking variable” scenario. Imagine we are analyzing the following data for two surgeons:

  1. Surgeon A operated on 100 patients; 95 survived (95% survival rate).
  1. Surgeon B operated on 80 patients; 72 survived (90% survival rate).

At first glance, it would appear that Surgeon A has a better survival rate — but do these figures really provide an accurate representation of each doctor’s performance?

Deeper analysis reveals the following: of the 100 procedures performed by Surgeon A,

  • 50 were classified as high-risk; 47 of those patients survived (94% survival rate)
  • 50 procedures were classified as routine; 48 patients survived (96% survival rate)

Of the 80 procedures performed by Surgeon B,

  • 40 were classified as high-risk; 32 patients survived (80% survival rate)
  • 40 procedures were classified as routine; 40 patients survived (100% survival rate)

When we include the lurking classification variable (high-risk versus routine surgeries), the results are remarkably transformed.

Now we can see that Surgeon A has a much higher survival rate in the high-risk category (94% v. 80%), while Surgeon B has a better survival rate in the routine category (100% v. 96%).

Let’s consider the second scenario, where numerical values can change results.

First, imagine that every month, the results of a patient satisfaction survey are exactly the same (Table 1).

patient-satisfaction-survey-table1

The Table shows that calculating an average of each month’s result produces the same result (90%) as calculating a Weighted Average (90%). This congruence exists because each month, the denominator and numerator are exactly the same, contributing equally to the results.

Now consider Table 2, which also displays the number of responses received from a monthly patient-satisfaction survey, but where the number of responses and the number of patients who report being satisfied differ from month to month. In this case, taking an average of each month’s percentage allows some months to contribute to or affect the final result more than others. Here, for example, we are led to believe that 70% of patients are satisfied.

patient-satisfaction-survey-table2

All results should in fact be treated as the data-set of interest, where the denominator is Total Responses (2,565) and the numerator is Total Satisfied (1,650). This approach correctly accounts for the fact that there is a different number of values each month, weights them equally, and produces a correct satisfaction rate of 64%. That is quite a difference from our previous answer of 6% — almost 145 patients!

How we calculate averages really does matter if we are committed to understanding our data and reporting it correctly. It matters if we want to identify opportunities to improve, and are committed to taking action.

As a final thought about averages, here is a wryly amusing bit of wisdom on the topic that also has the virtue of being concise. “No matter how long he lives, a man never becomes as wise as the average woman of 48.” -H. L. Mencken.

I’d say that about sums up lurking variables and weighted averages — wouldn’t you?

– See more at: http://ksrowell.com/blog-visualizing-data/2014/05/09/is-an-average-of-averages-accurate-hint-no/#sthash.WCltUtKb.dpuf

Untitled-1

Thoughts from a Recent Graduate

 A look at the Brandeis GPS student experience through the eyes of recent graduate from our Master of Software Engineering Program, Megan Tsai. 

My time with Brandeis GPS has been very helpful for my career. This is a feeling shared by all of my fellow GPS graduates. During commencement, IMG_1230the student speaker shared his experience of taking a discussion or an idea from class and applying it directly to his job. Many of the GPS graduates sitting in front of me were nodding their heads in agreement. There were several times I was able take what I had learned just the night before and take my work to the next level.

As one of the few students in an entry level position in all of my courses, my experience in the master’s degree program involved mostly sharing my perspective as an entry level worker. This allowed me to gain career advice from experienced fellow students and instructors. GPS courses are not just for established workers with years of experiences under their belt. GPS courses are for anyone who wants to advance his or her career, exchange ideas with people from different backgrounds, and catch up on the latest technologies and techniques. 

The types of cIMG_1262ourses offered allow software engineers of different capacities to learn something new. The fact that GPS courses are online helps professionals living around the world connect through an academic environment. The online courses also allow busy people find  time in their day to complete the course requirements. Ten courses may seem impossible for any one busy with work, life and other commitments. However, the flexible nature of GPS courses will help anyone achieve the dream of obtaining an advanced degree.

Advice at Rabb ceremony: ‘Geek Out’

Original Post: http://www.brandeis.edu/now/2014/may/commencement/rabb.html

by: Leah Burrows

rabb620

In Sunday’s kickoff diploma ceremony, the Division of Graduate Professional Studies at the Rabb School of Continuing Studies conferred nearly 100 graduate degrees and certificates on a diverse group of professionals from across the country and around the world.

The ceremony awarded graduate certificates and master’s degrees in bioinformatics, information security, information technology management, project and program management, health and medical informatics, virtual management and software engineering.

The graduates, most of whom worked full-time jobs as they pursued their degrees and certificates, shared the spotlight with their families, who were praised for their support and patience.

“Friends and family members should get a graduate degree in understanding,” said Anne Marando, executive director of the Division of Graduate Professional Studies.

Student speaker Robert Havasy, MS ’14, agreed, thanking his family for “propping me up when I thought about quitting, when the work seemed too much.”

Havasy, the corporate team lead for product and technology development at the Center for Connected Health, highlighted the differences between Rabb graduates and others receiving their degrees on Sunday.

Many of these students will spend the next few years figuring out what they want to do, struggling to find their place in the work force and searching for a mentor, Havasy said.

“What makes Rabb unique is the vast majority of us came here from established careers,” Havasy told his fellow graduates. “We will return to work next week or, more likely, tomorrow. We will become mentors to these students. So spend time with your interns, use your influence to promote diversity, civility and integrity in the workplace.”

Eric Siegel ’91, the founder of Predictive Analytics World and Text Analytics World, gave the keynote address. He urged the graduates to “do what you love and love what you do.”

EricSeigelStudent“My advice to you is geek out,” Siegel said. “Get into it. Find that thing in your work you get a thrill out of.  The holy grail in your work life is finding that thing that gives you a kick.”

Siegel, the executive editor of Predictive Analytics Times and the author of “Predictive Analytics: The Power to Predict Who Will Click, Buy, Lie, or Die,” received his bachelor’s degree from Brandeis in computer science.

He shared his own experiences geeking out about predictive analytics, theater and teaching. The self-proclaimed “singing professor” lived up to his name, serenading graduates with a few verses from his songs about problem solving and analytics.

“It is a priority to find the fun in your work life,” he told the graduates.

Pursing an education while working a full-time job wasn’t always fun for many of Sunday’s graduates but it was fulfilling.

“This was such a rewarding experience,” said Rocky Moscoso, who received a Master’s of Software Engineering. “I had 14 years of experience in the field before coming to Brandeis and I was able to use what I learned at work in the classroom and visa versa.”

Veronica Orozco, who also received a Master’s of Software Engineering, agreed.

“This experience was insane, overwhelming and totally worth it,” she said.

About the Author:

Leah is the  News and Communications Specialist at Brandeis University, generating content for the university’s website and magazine. Leah also writes for her own blog: wordsbyleah.com

Cloud Computing and the OpenStack Advantage

by: Nagendra Nyamgondalu, Senior Engineering Manager at IBM India and Brandeis Graduate Professional Studies Master of Software Engineering Alum

It was only a few years back that most IT managers I spoke to would smirk when they heard  the  term  “cloud” in  a  conversation.  They  either  didn’t  believe  that  cloud cloud-iaas computing  would  be  viable  for  their  businesses’  IT  needs  or  were  skeptical  about  the maturity  of  the  technology.  And  rightly  so.  But,  a  lot  has  changed  since  then.  The  technology, tools and services available for businesses considering adoption of a public cloud, setting up their own private cloud or treading the middle path of a hybrid one, has  made  rapid  strides.  Now,  the  same  IT  managers  are  very  focused  on  deploying  workloads and applications on the cloud for cost reduction and improved efficiency.

Businesses  today  have  the  choice  of  consuming  Infrastructure  as  a  service  (IaaS),  Platform as a service (PaaS) and Software as a service (SaaS). As you can imagine, these models map directly to the building blocks of a typical data center. Servers, storage and networks form the infrastructure on top of which, the required platforms are built such as databases, application servers or web servers and tools for design and development. Once the two foundational layers are in place, the applications that provide the actual business value can be run on top. While all three models are indisputable parts of the bigger picture that is Cloud Computing, I have chosen to focus on IaaS here. After all, infrastructure is the first step to a successful IT deployment.

Essentially, IaaS is the ability to control and automate pools of resources, be it compute, storage,  network  or  others  and  provision  it  on-­‐demand.  Delivering  IaaS  requires  technology  that  provides  efficient  and  quick  provisioning,  smart  scheduling  for deployment  of  virtual  machines  and  workloads,  support  for  most  hardware  and  of  course, true scalability. OpenStack is an open source framework founded by Rackspace Hosting  and  NASA  that  takes  a  community  approach  to  make  all  this  possible.  It  was  designed  with  scalability  and  elasticity  as  the  overarching  theme  and  a  share­nothing, distribute-­‐everything approach. This enables OpenStack to be horizontally scalable and asynchronous. Since inception, the community has grown to a formidable number with many  technology  vendors  such  as  IBM,  Cisco,  Intel,  HP  and  others  embracing  it.  The  undoubted advantage that a community-­‐based approach brings, especially to something like IaaS, is the extensive support for a long list of devices and cloud standards. When a new type of storage or a next generation network switch is introduced to the market, the vendors have a lot to gain by contributing support drivers for their offerings to the community. Similar support for proprietary technology has dependencies on customer demand and the competitive dynamics amongst the vendors -­‐ this almost always results in delayed support, if that. While proprietary versus open source is always a debate, the innovation and cost benefits that open alternatives have provided in the recent years, has  clearly  made  CIOs  take  notice.  Support  for  a  variety  of  hypervisors,  Open  APIs,  support  for  object  or  block  storage  and  the  mostly  self-­‐sufficient  management capabilities are some of the common themes I hear on why businesses are increasingly adapting OpenStack. Additionally, the distributed architecture cloud_securityof OpenStack where each component (such as Compute, Network, Storage & Security) runs as a separate process connected  via  a  lightweight  message  broker,  makes  it  easy  for  ISVs  looking  to  build  value-­‐adds  on  top  of  the  stack.  All  the  right  ingredients  for  a  complete  cloud management solution for IaaS.

Most  IT  managers  dream  of  the  day  when  every  request  for  infrastructure  is  satisfied  instantly by the click of a button regardless of the type being requested, workloads run smoothly and fail-­‐over seamlessly when there is a need to, resource usage is constantly optimal  and  adding  additional  hardware  to  the  pool  is  a  smooth  exercise.  Business  managers dream of the day when they have instant access to the infrastructure needed to run their brand new application and once it is up, it stays up. Aaah Utopia.

The good news is it is possible here and now.

21495fc

 

Nagendra Nyamgondalu is a Senior Engineering Manager at IBM in India. He is a 2003 graduate from Brandeis University, Graduate Professional Studies’ Master of Software Engineering Program.

 

Design Your Agile Project, Part 1

by: Johanna Rothman

Find the original post here: http://www.jrothman.com/blog/mpd/2014/03/design-your-agile-project-part-1-2.html

The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)

One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone,without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)

I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.

Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.

The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.

How Does Your Product Release?

I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:

Potential Release Frequency

How expensive is it to release your product? The expense of release will change your business decision about when to release your product.

You want to separate the business decision of releasing your product from making your software releasable.

That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.

The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.

How Complex is Your Product?

Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:

CynefinI’ll talk more about you might want to use the Cynefin model to analyze your project or program in a later post. Sorry, it’s a system, and I can’t do it all justice in one post.

In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.

Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.

As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.

Where Are We Now?

Here are my principles:

  1. Separate the business decision for product release from the software being releasable all the time. Whatever you have for a product, you want the software to be releasable.
  2. Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
  3. Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
  4. Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.

If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.

This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.

Johanna Rothman

Who Solves Which Problems?

by: Johanna Rothman

AgileMany years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

BarGraphI don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Original Post: http://www.jrothman.com/blog/mpd/2014/04/who-solves-which-problems.html

Johanna Rothman

footer

Protected by Akismet
Blog with WordPress

Welcome Guest | Login (Brandeis Members Only)