The Brandeis GPS blog

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

Tag: Information Technology Management (page 2 of 2)

My Journey in Online Learning

The M.S. in Project and Program Management program at Brandeis GPS through the eyes of a recent graduate, Thomas Gratiano.

ProjectManagement_03Three years ago as the manager of the Program Management Group within the Manufacturing and Global Supply Chain (MGSC) Division, my manager challenged me to build my business acumen. To meet this challenge, I started researching: certifications, certificates, and degree programs.

Eventually I came across the Brandeis program, the curriculum was exactly what I was looking for to build on my existing Program Management skills. During the pursuit of my degree at Brandeis I took four classes on campus and six online.  Although I was hesitant at first about taking online classes, the online option provided an increased level of flexibility.  This proved to be a key feature of the program as I ended up Program Managing two projects with our team in Belgium while attending classes online. I was able to travel as often as required with no impact to my ability to participate in class. e-Learning Concept. Computer Keyboard

Upon completion of my degree, I was promoted to senior manager in charge of Framingham manufacturing operations and the MGSC Program Management group. The Brandeis degree built my business acumen and provided me the opportunity to continue to grow with my company. 

Are You Running from Problems or Solving Them?

By: Johanna Rothman

Originally from:

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

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.



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:

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

Graduates with Roots in STEM Face Growing Career Opportunities


As we enter May, young people here in Boston and across the country are about to embark on a new chapter in their lives. Many will be graduating from college and taking their first step into the great, wide, professional world. Question marks fill their future as they wonder what kind of opportunities await them and their hard-earned bachelor’s degrees.

While it is impossible to forecast the job market with absolute certainty, it is undeniable that the fields of science, technology, engineering, and mathematics (STEM) hold the greatest opportunities for job seekers now and in the future. Industries like renewable energy, healthcare, advanced manufacturing and technology are rapidly growing and demand increasing numbers of skilled workers to sustain their expansion.

The computer and math occupations account for close to half of all STEM employment, followed by engineering with 32 percent, and then physical and life sciences at 13 percent, according to U.S. Department of Commerce. Significant growth is projected for computer and mathematical scientists, engineers and engineering technicians, architects and architectural technicians and more STEM occupations.

Those with strong STEM education backgrounds “will find themselves at the center of our new economy,” tech expert Vinay Trivedi said in the Huffington Post.

But unfortunately demand is outpacing supply when it comes to STEM-related careers. Fewer students are pursuing advanced math and science degrees, creating a problematic skills gap threatening the United States’ position in the new global economy.

The U.S. ranks 30th in math and 23rd in science, according to latest Program for International Student Assessment; and the latest ACT results show that only 44 percent of our high school graduates are ready for college-level math, and just 36 percent are ready for college-level science, the National Math & Science Initiative reported.

The impact of the skills deficit which develops in secondary level education has deleterious consequences once those students reach college. Many students abandon interest in STEM career by the end of their sophomore year, Irv Epstein, Professor of Chemistry at Brandeis University, observed.

It is a national imperative to reverse this trend. President Barack Obama declared creating the next generation of STEM leaders an educational priority for the nation at his State of the Union Address in January.

“I also hear from many business leaders who want to hire in the United States but can’t find workers with the right skills. Growing industries in science and technology have twice as many openings as we have workers who can do the job. Think about that–openings at a time when millions of Americans are looking for work,” he said. “That’s inexcusable. And we know how to fix it.”

Many have answered President Obama’s call to improve STEM education. In addition to early education initiatives, select colleges and universities have stepped up including Brandeis University who has partnered with the Posse Foundation to provide merit-based scholarships to minority students interested in pursuing STEM degrees.

But meanwhile, as programs launch to serve the next generation of students, the STEM jobs are still waiting, available for current job seekers who have the skills and ambition to seize the opportunity.

For those who lack adequate STEM skills but are eager to break into expanding, innovative industries, there is a way for them to bridge the skills gap: graduate education. Don’t wait for a job to pop up that fits your resume. Act now to get the training you need for the jobs available.

Original Post:

Watch Your Language: How Security Professionals Miscommunicate About Risk

Author: Derek Brink

Original Post:

What a joy it is to be understood! Yet many security professionals find it difficult to be understood by the business decision-makers they are trying to advise.

“They just don’t get it,” we say. And we grumble that our committed, faithful, and honorable efforts to protect the company and its assets are under-recognized, under-appreciated . . . and under-funded.

riskWe could try speaking louder, and more slowly—the comedic memes for how we instinctively try to communicate with someone who speaks a different language.

Of course, we could start trying to speak the same language. That would probably yield better results.

The way we talk about risk is a prime example of how we habitually miscommunicate. Security professionals mistakenly think they are talking about risk, when they are, in fact, talking about threats, vulnerabilities, and exploits. Some examples include

  • Phishing attacks: This is not a risk. It’s an exploit of a very common vulnerability (humans).
  • OWASP Top 10: These are mistakenly described as “The 10 Most Critical Web Application Security Risks,” but they are not risks. They’re vulnerabilities and exploits.
  • Advanced persistent threats: This isn’t a risk. It’s a threat. (Even when we get the name right, we get it wrong.)
  • Rootkits: This is not a risk. It’s a type of exploit.

As security professionals, we tend to go on and on, talking about threats, vulnerabilities, exploits, and the technologies that help to defend against them, and we think we’re talking about risk. Meanwhile, the business decision-makers we’re trying to advise are confused and frustrated.

So, what is the right language? What is risk?

Shon Harris, author of the popular CISSP All-in-One Exam Guide, defines risk as “the likelihood of a threat agent exploiting a vulnerability, and the corresponding business impact.” Douglas Hubbard, author of The Failure of Risk Management: Why It’s Broken, and How to Fix It, defines risk as “the probability and magnitude of a loss, disaster, or other undesirable event.” (And in an even simpler version: “something bad could happen.”)

To be very clear, it’s not that there are multiple definitions of risk, or that the definition of risk is unclear. It’s that we as security professionals aren’t speaking the right language. When we speak about security risks, we should be speaking about the probability of successful exploits, and the magnitude of the corresponding business impact.

Imagine yourself in the role of the business decision-maker, and imagine that your subject matter experts presented you with the following assessment of risks related to endpoint security:

  • Cleverly engineered stealth malware, rootkits, is designed to evade detection, and persists on endpoints for prolonged periods of time. And new strains of malware are targeting an area of endpoints that performs critical start-up operations, the master boot record, which can provide attackers with a wide variety of capabilities for penetration, persistence, and control. In both cases, we may already be infected, but not even aware.
  • There is a 15 percent probability that an endpoint security exploit will result in business disruption and productivity losses that may exceed $5M.

internet-security1Which of these would be more helpful to you in terms of informing a decision about endpoint security? (It should go without saying that this point could just as easily apply to managing identities and access, or data protection, or application security, or mobility initiatives, and so on. Endpoint security is just an illustrative example.)

Clearly, the second option is more helpful. And the second option is properly framed in terms of risk.

In no way does this guarantee what the actual decision will be. One decision-maker might conclude, “I approve your request to invest in additional endpoint security controls to reduce this risk,” while another decision-maker might conclude, “that’s a risk I’m willing to live with.” But that’s okay—as security professionals, we will have done our job.

By better understanding how to communicate about security risks, we will also enjoy the benefits of being better understood.

About the Author:

BA8D94F2924E634831C8CA3D8E7179C7477BBC1Derek E. Brink, CISSP is a Vice President and Research Fellow covering topics in IT Security and IT GRC for Aberdeen Group, a Harte-Hanks Company. He is also a adjunct faculty with Brandeis University, Graduate Professional Studies teaching courses in our Information Security Program. For more blog posts by Derek, please see  and

Just Announced: Eric Siegel as GPS Commencement Speaker

eric_med_3Brandeis Graduate Professional Studies is pleased to announce our 2014 Commencement speaker for the Rabb School of Continuing Studies Diploma Ceremony, Eric Siegel, PhD.

Eric completed his undergraduate degree from Brandeis University in 1991, and subsequently earned his PhD from Columbia University. Eric is the founder of Predictive Analytics World and Text Analytics World. He is the Executive Editor of the Predictive Analytics Times, and he makes the how and why of predictive analytics understandable and captivating. Eric is the author of Predictive Analytics: The Power to Predict Who Will Click, Buy, Lie, or Die and a former Columbia University professor who used to sing to his students. He is a renowned speaker, educator, and leader in the field. He has appeared on Bloomberg TV and Radio, Fox News, BNN (Canada), Israel National Radio, Radio National (Australia), The Street, Newsmax TV, and NPR affiliates. Eric and his book have been featured in Businessweek, CBS MoneyWatch, The Financial Times, Forbes, Forrester, Fortune, The Huffington Post, The New York Times, The Seattle Post-Intelligencer, The Wall Street Journal, The Washington Post, and WSJ MarketWatch.


Following Your Storyboard: Key to Effective Presentations

By: Phil Holberton

Original Post from:

marketing-sales-presentationsPutting your storyboard together is one of the most important activities of preparing to give a presentation. Each storyboard should contain the following elements.

  • Opening
  • Main Points
  • Supporting Points
  • Details – For Clarity
  • Closing

I’m often amazed when I see corporate business plan presentations. They look like the preparer took all the information in his or her head and dumped it into a PowerPoint® presentation. Not only do they seem just a data dump, but they don’t communicate the necessary information–they prevent the audience members from comprehending what is important. Our job as leaders is to convert/translate data into information, adding our interpretation and wisdom to the content.

Many corporate presenters are communicating very complex information–much of it scientifically — or technically-based. Sometimes the information is so technical and complex that it is over the heads of audiences. The first activity that every presenter needs to focus on is, “who is your audience?” Understanding the capacity of your audience will help you design your storyboard. The real challenge comes when the audience capacity is so broad that you have equal risk of speaking down to people as you do of speaking beyond them. One gifted presenter I have the pleasure of knowing and working with will spend time developing a simple primer of the subject to be covered, starting out with simple statements and examples, and escalating the degree of complexity, thereby bringing his audience along. Less skilled presenters will start right in on their subject without any warm-up–and they lose their audience at the very beginning. This is especially common when a presentation builds upon preceding theories. Once you lose your audience, it is difficult to get their attention back.

From the list of storyboard elements, start with the last one, developing your closing, first. Always begin with the end in mind. What do you want your audience to take away from this presentation? Is it information? Do you want them to move to action? Knowing this in advance will help you build your presentation. After you are clear about the outcomes, then you can begin to put your main points into place.

“In the beginning…” Isn’t this a famous saying? Well, in the beginning of your presentation, you need to set the tone of what you intend to cover and lay out the framework of where you are headed. Establishing a bond with your audience is key to gaining their confidence in you as the presenter of the information. Look audience members in the eye, use pauses effectively, and open strongly by sharing with them the scope of your subject and what your approach in presenting it will be. At some level, you are “selling” them on listening to you. And, let’s face it, we are all nervous when we begin a presentation, but don’t use jokes to fill an empty space and don’t set expectations that you can’t fulfill. All along, we want a style of presentation that establishes credibility with the audience–not by telling them how good we are, but instead by sharing examples that support our material and demonstrate our expertise. Being perceived as an expert is paramount to delivering an effective presentation. This convincing can be quick for some, but for other audience members, it may take some time.

Reach_Your_AudienceIn our presentation, we want to identify the two or three main points that we would like our audiences to remember. These main points must be reinforced throughout our presentation. Repetition does not necessarily hurt. Many times, presenters are so enamored with all the material they know about a particular topic that they just carry on with so much detail that it is impossible for the audience to absorb all the content. This data dump, as opposed to the communication of relative information, adds confusion instead of clarity. Details should add clarity to the subject, not burden the audience with superfluous data.

As presenters of information, you should add your “spin” or “wisdom” to the content. Part of the presentation objective is to communicate content with color and part of the color is your opinion. Just make sure that your opinions are supported with information. Opinion is the value add that we provide as the deliverer of the content.

Unfortunately, we (me included) often feel so pressed for time, that we bypass the important step of building the storyboard, moving directly to creation of the presentation. Take an hour or so of quiet and map out your presentations. Like most important activities in our lives, if we take the time to plan, we will be happier with the outcomes.

Now ask yourself… “Am I a Leader?”

About the Author:

Philip Holberton, BA, CPA, is the founder of Holberton Group Inc – Speaking of Leadership, a business advisory firm specializing in strategic, organizational, and executive coaching. He is an adjunct faculty at Brandeis University Graduate Professional Studies and serves on our Professional Advisory Board.

Mr. Holberton is the author of the popular blog – Speaking of Leadership. 

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:

Johanna Rothman


My Journey as an “Adult” Student

adult-studentOk so here I am, I was told at work that I need to take a course for professional development…really? I already have my master’s degree, I thought I was done with school. Although I did always think that I would be one of those people that was a lifelong student. It has been 10, 11, 12 years maybe since I last took a “real” course. You know what happens, life….marriage, kids, house, etc. etc. all the excuses, I mean, reasons why I haven’t taken any courses since my master’s degree. I must admit this pit in my stomach may be fear or is it excitement? How can I fit a 10-week, 3-graduate credits, minimum 3 posting a week course into my 2 kids (4yr old and 1 yr old), husband, house, full-time job, 2+ hour commute schedule? As I sit hear waiting for fall registration to open, I think the pit in my stomach is excitement and not fear. I’m going to learn again.

Blog CTA main

Newer posts »

Protected by Akismet
Blog with WordPress

Welcome Guest | Login (Brandeis Members Only)