Three Secrets to Building Your Influence, Part 3, Shared Interests If you want to change anything in your organization, you need to influence at least one other person to succeed. I wrote about showing your competence in Part 1. Part 2 was about building trust. Now, let’s talk about creating win-wins with shared interests. I bet you’ve met people who […]
A client wants to know how best to calculate their software capitalization. They had a “standard” approach when they used waterfall. They no longer have all waterfall projects. They’ve started to use agile approaches. And, the projects don’t all look the same. Being somewhere in the middle means they’re having trouble reasoning about capitalization. Why
Three Secrets to Building Your Influence, Part 2, Trust If you want to change anything in your organization, you need to influence at least one other person to succeed. I wrote about competence in Part 1. This part is about trust. How do people trust you? They might expect you to be predictable in two ways:
Back when I was a manager, my senior management wanted to separate the “new” work from the “maintenance” work. I suggested that every new line after the first line of code was maintenance. The managers poo-poohed me. My concern: How would the “new” developers learn from their mistakes? I lost that discussion and I managed
In my experience, too many projects are under too much pressure. The sponsors want all of the features, completed in too-short time, with no defects. And, if possible, the sponsors think the project should cost nothing, the team should not need any training, and the team can work in any way, regardless of the desired
Three Secrets to Building Your Influence, Part 1, Competence If you want to change anything in your organization, you need to influence at least one other person to succeed. Mary, a leader in the organization, wanted to help her colleagues consider a variety of agile approaches. The organization had chosen a framework, and the framework
I wrote about how to pick a driver in Part 1. In Part 2, I wrote about how you might finesse some of the constraints and floats if you can release frequently. What if you’re like this organization, Acme? Acme has been working towards agility for the last couple of years. However, they still have
In Part 1, I wrote about the origins of drivers, constraints, and floats. I needed them when we only could release the project once to the customers. You saw the questions that help people choose the project driver. What about the constraints and floats? I think of constraints as bounding the project inside the driver,
Do you know your project’s bounds? Do you know what your sponsors want from your project? For many years, I heard about the “iron triangle.” Sometimes, the triangle was “Scope, Quality, Cost.” Sometimes, it was “Scope, Date, Cost.” It was always three things out of a minimum of four possibilities. I never saw a triangle
Do I advocate insubordination? Some of my Modern Management Made Easy technical reviewers wonder. And, when I looked at this definition of insubordination, I had to agree. However, when I read that definition, I don’t see any mutual problem-solving. I also don’t see any mutual purpose or respect. I don’t see how that form of