Who should read this: Anyone remotely connected with IT! Tips: Be sure to click through the links – there are some cool videos and tools we use that you might find helpful. (1) Start with an official charter meeting – even if it is a 1 day project, and list everyone involved in…
Who should read this: Anyone remotely connected with IT!
Tips: Be sure to click through the links – there are some cool videos and tools we use that you might find helpful.
(1) Start with an official charter meeting – even if it is a 1 day project, and list everyone involved in the project
It just makes the project official. Create a document, project asset, minutes or it can even be an email to all involved stating (a) project name, (b) project manager, (c) team and responsibilities (could have a RACI if it is a more involved project), (d) briefly, what the project is going to achieve (broad scope)
(2) Create a scope baseline, get it signed by the project champion and make it visible to every stakeholder
We call it “spec freeze”. Scope, simply put, is the sum total of what the project needs and agreed upon by all parties. The reality is that the scope is forever changing. James in Accounting thought of something new, Mark in procurement had a better idea, Jill in Inventory thought of one exception…you get the picture. We create detailed wireframes upfront – it can be time consuming, but it is totally worth it. EVERY TIME. It gets the project “live” in front of the end user before we even start to develop. So once James, Mark, Jill and the gang is sure (at least as of now!) we stamp it as a “scope baseline”. Any change is recorded but it is kept in a queue till after we deliver on that initial scope baseline. For the customer they see an end and not an unending project with changes upon changes. It keeps our development, testing and implementation clean.
(3) Research and find out all the negative stakeholders (not just the positive ones)
Every project has at least 1 negative stakeholder, someone who is negatively affected by the outcome of the project. It could be a person, a department, a customer, a vendor, a belief or even a competitor. Sometimes such impacts cannot be avoided. But it is a good idea to know how to work through them. Surprises are never pleasant during a software development project.
(4) Create 2 specs – one for the techies and one for the business folks and make sure they are both synced with the scope
In any software development project you will have to find out who the main consumer of the software will be – it can be 1 or more users. That user or users will be able to articulate what the project needs to do. As a software architect and also as a project manager you should be able to see the software from the eyes of the business as well as the eyes of IT. If you cannot do this, then make sure you have someone who can do that or tag team. When you are creating the specifications, create a user spec and a software spec – make sure these are in sync. Updates to one should update the other and communicated to the right parties.
(5) Regardless of your project management methodology (waterfall, scrum etc), make sure you have a detailed work breakdown structure
Take a project. Break it down into modules – a module is a finite part that can be developed and tested independent from the rest. Now take each module and break it into tasks. A task is a finite part of a module that can be measured start to finish – one to which you can clearly add a start and an end date. Next take the task and break it (if you can) into chunks that makes it easy to estimate time. There are many ways to estimate time – but increments of 2, 4, 6 or 8 hrs works for us. So 5 hrs is 6; 3 hrs is 4 (round up). We also use PERT methods if there are several unknowns in the beginning.
(6) Write out the test plans in a bug management system – it could even be google docs or excel – but write it down
When you articulate and write down a test plan your testing becomes more methodical. The project can be just 1 text box and 1 button. But when you start to write it out in steps 1, 2, 3 etc you will see a 4th test that you would have probably missed. You may use automated testing tools, but for functional testing this is a must.
(7) Track progress daily – project the finish line based on current completion
Especially true for those long projects, spread across multiple teams, time zones and sub projects (more like a program). A daily top down view of the project milestones, KPIs like burndown charts or % completion or earned value measures should be assessed daily – you can do it start or end of the day. Surprises spring when a project is “sleeping” or on “auto-pilot” – those are not good words for a software development project. It needs to be tracked, monitored and managed. DAILY.
(8) Keep communication channels open across all team members
Getting mathematical! Number of channels = n*(n-1) – so if 5 people are involved, that creates 5*4 = 20 channels – that is a lot of communication! The single most reason why projects fail is lack of clear communication and open channels. Daily 15 minute meetings (scrums) is one good solution. It should be unofficial – answer 3 questions – what did you do yesterday, what will you do today and what roadblocks are you facing to get the project done. Have each of the 5 people (or whatever the project team size) answer these. Another option is to use a collaboration tool like Basecamp, Producteev, Asana, Sharepoint, Zoho etc.
(9) Be honest – dead honest
If you messed up own up to it right then and there with an apology, but more importantly, with a way to fix it and how it will impact the work breakdown structure and the timeline. It lets the project manager recalculate, crash the project or rearrange resources etc.
If something is sensitive, but you feel it will affect the success of the project be honest and mention it, but mention it to the right person. First explain why you are going to talk about it and then explain how the situation will affect the project.
Politics is a great way to get things done! But politicking for the sake of it or to hide inefficiencies is a cancer to any project. Be honest and call it out if you see it. Create the “political arena” where it can be brought out to the key stakeholders.
(10) Always close the project, finished or not, successful or not
Let the project champion know “this closes the project.” Then write 1 (just 1) main lesson learned from the project. This really helps. At a glance you can see how many projects you have done (count the lessons learned!) and before starting a new project it is a good read.
Have a good time with everyone, enjoy the ride and remember “The goal of a software project is to solve a business problem. It is empowering when you know that your software will help a business to prosper.”
Roni has 16 years of experience in leading small to large scale IT projects for various markets. Roni successfully founded 2 companies spanning multiple locations and time-zones. He rolls up his sleeves and gets into software development anytime you ask him and database development is his passion – we call him “our sequel junkie”! Roni has a Bachelor’s in Engineering, his very valued PMP and is close to finishing his Global MBA from the coveted Warwick Business School in the UK. When asked about his personal life he says “We, my wife and 2 boys, live in the picturesque Hudson Valley region of New York. A Yankees and New York Giants fan, I also enjoy strumming my guitars every day, mixing recipes from different cultures when I get some time and hack away during an occasional round of golf.”