Agile Doesn’t Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.


But even in Agile, there is a beginning and an end to the sprint planning and project management.


Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 


Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 


Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).


We need to understand the difference between genuine customer service and irrational project exuberance based on inflated expectations. 


It’s not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  😉


(Source Photo: Andy Blumenthal)

Advertisements

Kanban Visual Task Boards

Just wanted to share this best practice for Kanban or Visual Task Boards


This is a way to layout work/workflow and track and communicate progress. 


Previously, many professionals use colored sticky notes on a wall or whiteboard.


Today, tools like ServiceNow have the capability built right in. 


This was an example that I created in just a few minutes. 


Visualize your team’s work and focus on what needs to get done, who the tasks are assigned to, the status, and keep driving continuous improvement in the workflow and project. 


Color coding can be used for different tasks and you can see the legend at the top.  

Tasks can be easily dragged and dropped from one column (status) to another. 


Create transparency and collaboration on your projects–try Kanban Visual Task Boards. 😉


(Source Graphic: Andy Blumenthal)

DMAIC Reengineering

A colleague gave a wonderful talk the other day on process engineering.


The key steps to reduce waste (Lean) or variation/defects (Six Sigma) are as follows:


Define – Scope the project.


Measure – Benchmark current processes.


Analyze – Develop to-be processes (with a prioritized list of improvements) and plan for implementation.


Improve – Executive process improvements.


Control – Monitor/refine new processes.


It was amazing to me how similar to enterprise architecture this is in terms of: defining your “current” and “future” states and creating a transition plan and executing it.


Also, really liked the Project Scoping questions:


– What problem do you want to solve/what process do you want to improve?

– Why do you need this?

– What is the benefit?  And to whom?

– What are your objectives for this effort?

– Who are the key stakeholders?

– When is this needed and why?


I think process improvement/engineering methodologies like this can be a huge benefit to our organizations, especially where the tagline is “Why should we change–we’ve always done it this way!” 😉


(Source Photo: Andy Blumenthal)

Project Manager – The DIRECT(or)

So I learned this cool acronym for the roles of a project manager:


DIRECT


The project manager directs the project (similar to a director who is the project manager of a movie).


Here is how the project manager DIRECTs the project:


Define – Identify the opportunity or issue that the project will address including, the vision, scope, resources, and measures of success. (i.e. the “Charter”).


Investigate – Explore options and pros/cons for each (i.e. an “Analysis of Alternatives”).


Resolve – Solve and resolve (i.e. commit to) the course of action that will be pursued (i.e. “Project Plan”).


Execute -Do the project and track/manage cost, schedule, scope, quality, risks, and actions items (i.e. “Scorecard”).


Change – Identify process and technology techniology changes, test these, fix outstanding items, and make the cutover (i.e. “User Acceptance Testing,” “Punch List,” and “Go Live Plan”).


Transition – Migrate people to the new solution, communicate the changes, overcome resistance, and conclude the project (i.e. “Communications Plan” and “Lessons Learned”).


(Source Photo: Andy Blumenthal)

Anything Is Possible

So you’re all aware of the 3 legs of project management:


– Cost


– Schedule


– Scope


I remember learning the adage that if you change any one of these then there is an impact on the others. 


For example, if you “crash” the timeline on a project to finish more quickly, then you either need more money or you need to reduce the scope. 


Similarly, if you want to cut costs on the project then you may have to extend the timeline or scale back on the requirements. 


Recently, I heard someone says the following:

“We can do anything with enough time and resources.”


And when I thought about this, it’s true enough.


If you provide more money and time for a project then, of course, you can do more in terms of the scope of the project.


Pour enough bucks and time into something and conceptually, we really can do anything. 


Technically, we can do the proverbial “anything,” but that’s only if the politics and infighting don’t get in the way of  progress. 😉


(Source Photo: Andy Blumenthal)

Supervisors vs. Team Leaders

Supervisors vs Team Leaders.jpeg

Here is a comparison of the roles and responsibilities of supervisors and team leaders. 


Often there can be confusion over who is supposed to do what. 


This table should help clarify what supervisors and team leaders do in terms of strategic planning, work assignments, resource management, employee training, and performance management. 


I hope you find this a helpful resource, and that you can organize your staff more efficiently and productively 😉


(Source Graphic: Andy Blumenthal)

Managing for Humpty Dumpty Risk

Humpty Dumpty.jpeg

So this was interesting…


I was in a meeting and someone was discussing the risks involved in a project.


And they mentioned the Humpty Dumpty Effect.


A bunch of people looked at them like what’s that. 


Then they explained that it’s the risk of breaking something during the project. 


Sort of like the Hippocratic Oath that doctors take to, “first, do no harm.”


When we are planning, designing, building or implementing a project–be it information technology or something else–we don’t want to break something in the process. 


That’s the Humpty Dumpty Risk to beware of and it’s an egg-celent point! 😉


(Source Photo: Andy Blumenthal)