I have been using Microsoft Project for years. There’s been a lot of love and a lot of hate. Often at the same time.
In my opinion, it is still the best available software for setting up project tasks and project dependencies.
Unfortunately, that is where the party almost always ends. The problem is that reality almost never follows the path we envision on Day 0. The timeline is not the only element that changes. What steps are required and the order of those steps ebb and flow as well throughout the project.
This is where the best part of MS Project also becomes its downfall: it is so good at identifying dependencies and assigning resources in order to build a nicely structured gantt chart, that the interdependencies are usually massive. When elements start to shift, the number of data points and task relationships that must be maintained becomes unwieldy.
Most PM’s realize eventually that nobody else on the team is really paying much attention to the project plan and they are spending inordinate amounts of time trying to keep it current, so they give up. In a horrible scenario, they try to deathmarch to the beat of the original plan. In a better scenario, they find an alternate way to track progress and predict success.
I have found MS Project is a useful tool at the beginning of a project to identify critical path. A critical path is the longest dependency chain. It is a set of tasks that if one of them slips, it will slip your entire project.
Once I am ready to begin a project, I slim it down to a format that the whole team can relate to and that can be kept up to date more easily. I also like frameworks such as IBM’s 7 keys approach which takes a much more holistic approach to project status tracking.
Anyone using MS Project all the way through a software development project? Anyone using agile and MS Project together in some way?
If you wait until a post-mortem to review what went wrong, you are already dead! It’s not going to help. 😦
Guy Kawasaki mentioned another approach on his recent Entrepreneurial Thought Leaders podcast appearance.
Before your effort fails, get everyone to close their eyes and imagine it has failed. Have each person describe the scenario that they believe could have led the team to that point. Then all you have to do is capture all the described wrong turns as risks and decide which ones are important to mitigate.
Just like so many good ideas, this idea’s simplicity is its genius. Participants will be emotionally involved and therefore will cut straight to the heart of the matter during an exercise that can otherwise be pretty dry.
Guy may have drawn the idea from this HBR article: Performing a Project Pre-Mortem.
Anyone ever tried it? If not, give it a shot and let me know what you think.
Agile development has shown itself to be a superior approach over waterfall in many cases. But, what I don’t see talked about much is the fact that each feature you pull off your backlog could be developed with a variety of complexities. If the business owner tells me that she needs to get from point A to point B, I could build her a Yugo or I could build her a Rolls Royce. I am sure she would prefer the Rolls Royce, but if you factor in the time to build it and the cost, she might prefer the Yugo or something in-between.
The first time you attempt something brand new, you can involve the stakeholders in the design/development, but you are never 100% sure how they are going to react once it is launched. So, it is best to build that feature relatively simply and then improve over time.
We use colors to denote the amount of resources that we are willing to dedicate to designing and developing a feature, process, or application.
Yellow is the lowest level. It represents our first attempt at something and it is usually a minimum viable product. We just want to solve the pain point so we can learn from it. Often it is very manually intensive to run a yellow feature because elements that could be improved via technology are not.
Green is the next level. At this point we want to build something that will not tax the operational team. A solution should be able to run at this color for a year or so without causing any major stress to the system. We are able to take what we learned from the yellow version to inform how the green system is designed/built. Occasionally we go straight to green, but only when we feel there are no workable yellow solutions.
Blue systems are designed to last for several years. They should be scalable, easy to manage, well-architected, and most of all, they should only be built after one has learned from earlier implementations of the feature. We sometimes go from yellow straight to blue, but we never build something at a blue level first.
This coloring approach is not nirvana. There are challenges
- How do you split your resources among the different colored projects?
- How do you decide to prioritize a blue version of something existing against a new yellow feature that is desired by stakeholders?
- How do you merge yellow, green, and blue staged elements into the same system (will they always plug and play)?
Anybody tried something similar? What worked and didn’t work for you?
My agile scrumtastic friend Andrew Tsui invited me to join him for an evening meetup of Agile NYC led by the master of all scrum masters, Ken Schwaber. My primary takeaway from the session is the importance attached to the definition of “done”.
Too many software development teams move onto the next set of desired features before they have reached a full complete, tested, and shippable state on the current set of features. This creates an over-estimated sense of the velocity at which the development team is progressing. Unfortunately, it is not as simple as the team picking up where they left off and completing the unfinished pieces before a customer release. Leaving loose ends in each iteration (sprint) is actually a compounding problem.
A team that consistently falls short of “done” ends up with a required stabilization stage which lasts much longer than the sum of all the missing elements from each iteration. The problem is easily rectified by allowing the development team extra time per sprint (short-term) in order to dramatically reduce the stabilization stage and save time in the longer-term (release).
Another nice side effect of slower velocity and increased amount of “done” per iteration is that the code base staves off the complexity that naturally slows velocity over time. Thus velocity can be maintained at a higher rate over a longer period.
On March 9 all of the PR focused hashtag communities got together under the banner of one common hashtag (#chatmixer) to discuss PR. While there is value in each different hashtag, there is also a lot of value in occassionally merging.
Here are a few write-ups of that experiment:
Kudos to them for their leadership. In this post I am talking about the general concept that they pioneered of blending hashtags.
One of the greatest advantages of a Twitter Chat is that there are no community walls. In fact, I think about it like a town square of old. Its always open for anyone to wander through on their way somewhere else or to explicitly go to for an event. Throughout the week people may see each other and share a few platitudes. One person or another may even bring a soapbox and share their ideas. Still others will post notes for people to find. All these behaviors are replicated in a Twitter Hashtag Community.
Once a week a crowd will gather to converse, debate, share info, etc…. With Twitter, each one of those who gather also have a direct line back to their block (followers) communicating just a portion of the conversation. A follower, whose interest is piqued by this flurry of posts on a single topic, may come and listen. Any time THEY start sharing, they develop a direct line back to their block…and so on.
A #chatmixer takes this concept a step further and starts to blend crowds that may have a lot in common. While twitter naturally breaks down walls between communities anyway, the #chatmixer can explicitly bring two or more together.
There are lots of different ways to make it happen. You can create a new hashtag like the PR folks did, but I prefer a different approach.
- For chats that take place weekly, you set up one chat on each of the hashtags that are participating.
- Each topic can be the same or different, but it should be of interest to the intersection of the communities. Eg. for #KMers and #innochat we did “How does KM support innovation“
- If each community has a website (Ning, blog, wiki, etc..), you post the other group’s chat day/time for your community to see.
- For the pre-event promotional tweets you encourage multi-hashtags to bring members from one community to the others’ chat.
There are lots of overlaps among the Twitter hashtag communities. Click here for a spreadsheet list. I hope we will see more of them getting together. If your twitter use has not evolved to the point of community involvement, jump in right away. Everyone is very friendly. 🙂
Twitter chats are simply pre-organized times to tweet on pre-organized hashtags. They use applications like twebevent or TweetChat to corral just those tweets together and to auto-tag any new tweets with the right hashtag.
The Chat Schedule was inspired by Meryl Evans, who started a blog post with a collection of all the chats she knew about. The new spreadsheet version began as a quick solution so that no one person had to track and manage the information about all the Twitter Chats. There were only about 25 chats back then. It has since grown into a list of hundreds of chats with several new ones added each week.
Everyone from journalists to moms to finance people to Knowledge Management professionals are finding each other and banding together via Twitter chats. See more info about the Twitter Chat Experience
I fully expected that someone would write a little database driven web app that would replace the public Google Doc, but perhaps simpler is better in this case.
Thanks to all who run the chats, all who have posted information about chats, and all who tweet the link to the list so that more potential chatters can find one that’s right for them.
View the schedule for yourself and add any chats you know about that aren’t listed.
In the last 5 years or so there has been a big move to lighter weight web-apps. This has been tremendously empowering to end users who can combine them in interesting ways to solve problems. While this often does not please the IT department due to circumventing established security, it does provide significant additional capability and flexibility for knowledge workers to gain access to functionality.
Teleconferencing used to be provided by large corporate accounts. Now anyone can obtain a free service on their own. Videocasting and web-conferencing is starting to go the same way. Services like Livestream and Ustream allow anyone to broadcast a video stream free to an audience. The pay version of those sites even allow you to white label, control access, and embed the broadcast into your own web pages.
There are plenty of webcasting solutions that will push slides: MS LiveMeeting, GotoMeeting are two of the low end ones. There are also many higher end providers. They often require downloads to make them work and many have additional complications like scheduling, passwords, etc… Why can’t we get light-weight slide pushing? Why do we have to go into a full web conference just to push a few slides (or photos) in real time to a colleague, a prospect, or even a friend?
Why can’t a simple meeting invite contain a link to a hosted page where my slides will appear as I push them through some lightweight client powerpoint plug-in? Services like SlideShare allow us to post a presentation file and even attach pre-recorded audio, but they cannot simply push a slide to another person or set of people live so that everyone gets the same slide at the same time.
So, it seems for now we have two choices
- Continue to hope everyone received the file (.ppt or other), has the right software to open it, and stays on the same slide as the presenter
- Pay for and use heavy webcasting services
The only reason I can image why this capability is not yet ubiquitous is that PowerPoint is so standard and perhaps people do not consider it a hassle to continuously tell everyone what slide they are on (or just let them figure it out for themselves based on the audio).
What do you think? Is this an open space for some innovation? Does anyone else feel like this would be useful?