Been in my position for now 90+ days and struggling
I spent the last 3 months fitting in trying to learn the system/infrastructure, politics,etc. I initiated O3s with my directs and have asked my directs which are supervisors to implement O3s (so far no push back)
Issue(s) I'm facing:
1. I'm in the technology field and part of my frustration is it has been difficult to come up to speed on their technology. It's not documented and the people do not provide detail (even if you ask direct questions) Very little training; Have others experienced this situation and how did they handle it?
2. I came on board with several projects already set / established with approved budgets Only to find out that the estimates used for the budgets are crap; I constantly find myself going to my boss to tell him of over-budget items. Have others experienced this situation and how did they handle it?
3. Lack of Cross Training is something that i see as a huge problem; I've identified it as an issue, developed a list of the current SMEs along with prioritizing the apps where we need cross-training; How do successfully get others to buy into the cross-train exercise?
4. No documentation for custom apps. So far, I've asked the developers to go back in and document as much as possible (workflows, ERDs, etc.) because my developers are new and struggle if asked about a new feature or potential bug; What have others done in this situation to make sure the new developers get up to speed quickly on a undocumented application where the client is asking for mods almost every other day?
Thanks. I'm just looking for some guidance.
1. Set goals for people to
1. Set goals for people to create documentation. "Create 1 binder with complete technical documentation about System X by April 1, 2009". Make the assigned supervisor with this goal understand that his raise and annual review depend on success.
2. Redmond's Axiom of Project Transition: The receiving project manager will always say "This project was done all wrong and now I am straightening it out" no matter the condition of the project or the usual condition of their own projects. :-)
I would just consider crap estimates in technology to be par for the course. Set someone a short term goal and delegate:
" I need your help. I would like for you to take these projects here back through estimation. You are the best person to do this because you know these systems and processes better than I do, and people know you better and you might be more response. Would you be willing to do that for me?" [Yeah, I guess.] "Cool. Here are the details... is there anything you need from me to be successful at this? The goal is for you to get these estimates to a state that I can stop going to the boss and talking about budget over-runs one at a time. I need this done by your O3 next week and want you to report in then without me asking after you. Can you do that? Cool. You da man."
3. Annual goals
4. See #1.
-Rob Redmond
http://www.strugglingmanager.com
Clarify your expectations
HI
as a former IT Auditor and now business/technology consultant I have seen this a lot. I have a major client who is replacing their data warehouse as they could not work out the code any more, and so could not substantiate any information in the EIS report!
1. I agree with Rob. There will be push back as the immediate always seems more important. You might want to make documentation a project and have its priorities set against other development. Within that project, priorities the applications order for documentation, and ensure that when any changes are made your new documentation standard (that you have trained your people in) is used and the surrounding code is documented whilst the are in there.
2. I have been known for killing the odd project and recovering many. In your situation I would go back to square one - what was the objective (from the business), it is still valid, what has been spent, what can be delivered with the remaining approved budget, will the return on investment be achieved. From this you may have the opportunity to kill some projects (your team will love you) and get the funding necessary to recover and deliver what is left. For this I would do a formal "Health Check" on each on every project and provide your director a consolidated view of the entire situations in relation to projects.
3. Cross training is a hard one. One of my clients had talking applications but did not even have a release management strategy that ensure that changes affecting other applications were taken in to account! I think this is a medium term issue, but one way might be to use the documentation approach where people document other peoples apps as a way of cross training, or using code QA processes as a cross training opportunity.
4. See 1 above, and ensure you have clear expectations and training in your documentation methodology, and incorporate that in people goals and measure them against it. As part of the QA process for code release, not only check the code but also the documentation.
Hope that helps.
Kind regards
Jason
Couple more thoughts
1. It takes a long time to get up to speed on new technology. In my experience, three months is not enough time to get up to speed. It's frustrating, yet you have to be realistic. Focus on managing the people for now. Rely on their technical expertise. That's why you were hired, right?
2. Software documentation is overrated. Yes, you need it. Most of it is worthless and never referenced. Having flows and swimlanes and ERD's is fine, but in your situation, you need a minimal set that supports maintenance activities, not designs that would be used to build (ie, waterfall artifacts).
Get a list of all components (files) built and installed, with a quick description of what they do, where the code is, and how the build scripts work. That is 50% of what the maintenance folks need to know.
There are tools that will create object diagrams, ERDs, etc automatically. Visual Studio will do this.
And if you want to motivate the developers to create it, make it clear to them that they won't be writing any (cool) new code until they create some simple useful documentation for maintenance. No handoff without it. They're resisting partly because they know no one will ever look at most of the design documentation they write. If you show you're willing to create only useful documentation, they'll be less resistant.
In the future, code reviews that rely on good commenting in source code will do more to ensure quality and maintainability than any other activity or documentation.
John Hack