Hi new visitor! At Green & White we discuss startups, business models, new media marketing, usability and more.
You can subscribe to the RSS feed or subscribe for email alerts so that you keep up to date with the latest content. Now, on with the regular content...
We’ve been through another series of courses this month, hence my disappearance from the blog recently. This month the theme was project management. Some of the interesting questions which came up across all three cities were related to just how much project management do we apply to our projects?
Veteran project managers from our industry all agree that PMBOK is a good thing, but its just not practical! “We dont get a budget” they say… or “procurement and HR are out of our scope”. “How can we cost when we dont even know how much people in my team are getting in terms of salary and perks?”. Some say that we utilize agile techniques, because they are more ‘closer’ to what we’re doing. But even then, ask them what makes up a good story (as in stories in XP) and they’ll launch into a tale about ‘woe is me’!
So what is practical then? what is just enough project management?
In my experience, project management practiced in our industry is as client-dependent as anything else. If the client says “plan!!” we plan, otherwise, we draw up a sorry excuse for a schedule and take it on gut feeling from there. The only answer I can come up with for this behavior is lack of accountability.
When PM’s aren’t accountable for what they did in previous projects, then they aren’t going to do anything seriously. The expectation from a PM by management is one and one thing only. To deliver a project (by hook or by crook) within the time frame and not screw up. Management doesn’t really care if they planned the project, if they winged it, or if they let someone else take over, the only matrix they have is meeting the deadline. And the manager who cant… well, “there’s plenty of good enough companies who will hire me… this company sucks anyway”.
Of course, you can deliver projects one at a time, (yes, management! i’m talking to you!!!) but can you make a company this way? Can you afford to keep repeating mistakes you know you do, and you know how not to as well? Can you afford loosing both valuable employees and paying clients just because you are not willing to expect more from your PMs but instead want to rub them into the ground?
Agree? Disagree or just want to flame me, you’re welcome to the comments section!
| Written by mansoor on 06/6/08 in Software & I.T. |
Loading ...
June 7th, 2008 at 3:02 am
I think that Project Management is the lifeline to any business that has to scale. How do you cope with all the details and competing resourcing? You might want to look at a blog that develops these ideas - http://www.vertabase.com/blog/ . I could not manage my business at all without the philosophy and tools that project management brings to the table.
June 7th, 2008 at 11:30 am
I, for one, would be most interested in finding out how on earth a local project is managed efficiently here in Pakistan. Take for example, my company, they develop software for Textile mills and the stock exchange and are bombarded with change requests every week! There’s not much room to follow the SDLC strictly, and it ends up being an extremely AGILE development model - one that doesn’t always bring about the best results.
June 7th, 2008 at 12:05 pm
roger: the philosophy that PM brings is a very good point that you’ve mentioned! i’ll think more along those lines as well. thanks
raza: the problem you’ve mentioned is very common, and i believed two sided. remember, the customer will keep demanding changes etc if they think its easy. and sadly, we developers let them keep thinking its easy because we want their business. a very simple suggestion to reduce change requests is something like this. formulate a change control board (or whatever name you’d like to give it) and have a senior member of the customer’s team on it. convene a meeting of it every week (or two) and present all changes requested by users along with schedule/budget impact of the change.
e.g. 10 changes requested in one cycle, with average schedule impact of 3 days per change, would eventually take the deployment up 30 days.
make sure the customer’s rep understands this, and make them sign off on all approved changes.
once they realize that project will be going 1) over cost or 2) over budget, then they’ll start prioritizing changes and your lives will be made much easier.
also, please dont say the client wont agree to this… because its upto your negotiation skills as a PM which will enable you to make them agree.
June 7th, 2008 at 1:06 pm
The problem isn’t accountability; it’s rather with our definition of “success.” In almost everything we do, we are extremely short sighted as a nation. So, “success” is usually defined as keeping the customer happy and getting the work paid. Developers’ satisfaction, company’s reputation, meeting budget constraints, etc. might all be of least importance to the management.
While this would work when you have a small team, just like a start up, it fails in the long run: when people are not emotionally bound with the company, they can easily switch jobs if the satisfaction level gets lower than their threshold.
Perhaps, extremely poor project management is one of the reasons we only have “small sized” IT companies in Pakistan. As soon as you cross 100 employees barrier, it all starts falling down.
June 7th, 2008 at 4:26 pm
Excellent discussion!
Would like to add that sometimes the business requirement is very genuine and it is important to deliver a few features every week. How on earth do we do that?
Well, there is one way … Test-Driven-Development …
It is a very useful concept but unfortunately not very popular in Pakistan. The idea is that you build/program a test before you write the actual code that does the job
When followed properly, it gives your project / support organization serious velocity!!
For example, on one project that we are currently working on, we have written programs that setup a full test environment complete with transaction data and dictionary data. We have even built in acceptance criteria because we already know that c=a+b
Now when we write the program “say program_x” that computes ‘c’ then we can run the test program before and after the program_x to find the expected result
It should also be highlighted that we should not expect the programmer to mentally calucation that if value of ‘c’ is withing 70-80 then the test has passed, instead the program should itself check this and just report PASSED or FAILED so that when these tests have grown to a large number all you need to worry about is whether all the tests PASSED after your modification took effect
June 8th, 2008 at 12:06 am
Hey Ansar - good to see you here. Thanks for the mention on your website about your book.
June 8th, 2008 at 12:31 pm
ansar: as they say in the world of acting.. “there are no small parts, only small actors”, i would like to adapt this to our own scenario. the saying would go something like this.. “there are no difficult projects, only difficult people”
i wonder if anyone has ever done a study on what is the most failed aspect of project management? from what i’ve observed (and this is by no means scientific) the area of most dissent would be communication.
June 8th, 2008 at 12:46 pm
ansar: i just saw the mention on your site too. thanks!
June 9th, 2008 at 9:02 am
I would agree with the fact that we do have load of paradoxes for managing the project at our ends, but I would like to add here is that we, as a project manager don’t even take the time nor effort to measure ourselves. Most Project Managers I have seen delve into more of communciation and negociation tasks, which might not project onto the tasks of measurement.
@ RogerS:
I would like to share the following links
I have been using GanntPV for scheduling and tracking my projects and have found it a lot better than MS project
http://www.pureviolet.net/ganttpv/index.html
http://www.simpleprojectmanagement.com/forum/index.php?action=vthread&forum=3&topic=81
http://voo2do.com/ (For keeping a task list and measuring what was actual versus planned.)
June 9th, 2008 at 12:18 pm
Thanks Osama and Mansoor! You are most welcome
Regarding Mansoor’s point about “communication” … I second that!!
June 10th, 2008 at 12:33 am
First of all, veteran project managers in the software industry do not agree that PMBOK style project management is a good thing. There are many, including myself, who believe it is a bad thing. It is wasteful, cumbersome, and hopelessly unrealistic to apply the PMBOK approach to software development projects. Building software isn’t like building houses, which is what PMBOK is derived from. You’ll be better off with a more lightweight, more flexible project management approach like Scrum, XP, or other agile approaches. Read Manage It! by Johanna Rothman, or any book by Mary Poppendieck and you’ll learn more.
Nice blog, btw. I’ve been following you for quite some time, as I’m interested in viewpoints of the software industry from around the world.
Dave
June 10th, 2008 at 1:37 am
Thanks Dave, you said what I was feeling reluctant to. Although I am a big fan of PMBOK in “theory” as it gives you a lot of knowledge, in the end you’ll loose your creativity in problem solving if you try to “follow” a book or even a particular approach. You’d have to come up with your own way to solve things. Best solutions end up being a hybrid of different approaches.
Variables in the real world change a lot faster than we might think. There are procedures to do things that can be bended for the better. So yes, “just enough project management” is variable subject to a lot of “changing” factors involved, people being one of them. Heck! emotional states of your team members matter too much, especially when you are subject to a high employee turnover rate (like the IT industry here) and you know it’s hard to find good help immediately.
June 10th, 2008 at 7:28 pm
I think we need to realize that at different stage different techniques are needed. Project management should be flexible and adaptable to the change..
We have a change control system, we meet every week to see what change requests are in the system and we evaluate them based on team inputs. If there is a developer estimate needed before we can make a decision we do that as well.
We use our in-house custom developed software for managing all the changes and so far it has been extremely flexible.
just my 2cents…
btw Ansar you might wanna move out from free hosting to something more decent for the site. The minute it loads up with that banner at the top it just discourages me to even consider the company for my next project.. just a friendly advice ..
June 11th, 2008 at 4:52 pm
Thanks for the advice ob!
It is a long painful story. We have a paid godaddy.com account but made the mistake of using the free “website tonight” software that came with the purchase
Will do something about it soon
June 11th, 2008 at 10:56 pm
salman: thanks for your input. what sort of measurements would you recommend for budding PMs??
ansar:
david: thanks for leaving a comment and not being a silent reader any longer. the veteran pm’s i was talking about were from our own industry and although there isn’t a authoratative study, the sample are those i’ve met personally. i’m all for lightweight, flexible PM strategies and thats precisely what i want to deduce… given the experiences we’ve had in our industry, what would constitute a good PM strategy and under what circumstances.. i hope this would give people a starting point to get PMship under control.
sayB: please say whatever is on ur mind.. this is a place for sharing of idea’s and we’ll all be richer for it. one point i’d tend to agree with you a lot is the emotional state of employees, something which management isn’t really keen to consider whenever considering productivity…. keep the idea’s coming!
ob: could you share more details about what exactly is your change management system? if you could share a high level process map for it…?
June 12th, 2008 at 9:35 am
@ mansoor:
I would rather start off with the simple measurements. “Planned versus Actual” start and end dates for any task.
Once this is performed, and logged, at the time of performing next estimation, we can always go to our logs and see to it, how much we estimated? Did we actually kept our word, or did we screw up the estimation completely. Next estimation must be an estimate, not a guesstimate.
Generally, I have seen project managers, using guesstimates, and never logging these simple things. Result: always complaining about not able to manage projects.
Off course, we need a real system like GTD, etcetera to do this.
Also, I feel that Project Manager should be managing their own lives, not just projects assigned to them.